krizhanovsky
commented
2 months ago We need to reuse the current kTLS code to
- not to have (and propose for the mainline) a 2nd symmetric TLS encryption
- benefit from the NIC accelerated TLS.
The 2nd point is important since NVIDIA closes the information about the NIC acceleration, for TLS and XDP offloads. The accelerating features may change dramatically between NIC generations or even models within a generation.
Linux kTLS works in socket context, so it constructs TLS records of maximum size or of size of available data. The TLS records formed in this way may exceed size of currently allowed transmission on TCP layer leading to extra delays in TLS decryption on receive side.
Traditionally, the problem is associated with TCP slow start, when congestion and/or send windows are small. However, suppose that we can send
Nsegments and already sent some complete TLS records inN-ksegments. We can send onlyksegments, which might be less than the size of complete TLS record. We'll send the rest of TCP segments when ACKs for the first sent segments arrive. It's unclear which delays practically may arise in this scenario. Probably high-bandwidth and high-RTT networks, e.g. cross atlantic, can show high delays here. This question must be evaluated.Tempesta TLS encrypts data in
sk_write_xmit()callback called bytcp_write_xmit(), when we know precisely how much data we can send. A patch with this approach must be prepared for the mail line kernel. Probably, receive side can be left as is.The problem is linked with #1434 and #1504 , Latency can increase for huge amount of TLS connections.