On 2/3/20 7:00 AM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> Viktor Dukhovni >> Sent: Sunday, February 02, 2020 11:10 >> >> On Sun, Feb 02, 2020 at 05:28:19PM +0000, Salz, Rich via openssl-users wrote: >> >>> TLS/TLS will take your data and wrap it inside it’s own record >>> structure. It has to, that’s the nature of the protocol. Thinking >>> that a single writev() is “encrypt buffers and then do analogous >>> syscall” is wrong. >> >> Right, the encryption is not in place, the user's data is copied for >> encryption, by which point there's no incentive for a writev between >> OpenSSL and the socket. > > True. There's still an argument to be made for a gather-write at the > application level, though. That would let the application say "here are > multiple buffers of application data which should be coalesced into as few > TLS records as possible, then encrypted and transmitted". It saves either a > temporary buffer and memory copy prior to calling SSL_write at the > application level, or sending short TLS records. > > Back in '01 I suggested it would also be useful for applications using the > BIO abstraction for both TLS conversations and for plaintext stream sockets. > Eighteen and a half years later, I suspect that's not a common use case. > > But in any case, as I noted in my previous message, if this enhancement is > sufficiently valuable to someone they can always implement it and submit a PR.
Note that kernel offloaded TLS (KTLS) changes the calculus on all of this as you could in fact do a single system call (hence SSL_sendfile()). One could perhaps have a SSL_writev() that did a single system call for KTLS and fell back to a loop of SSL_write() calls otherwise. However, you wouldn't have a SSL_readv() equivalent which might feel odd from an API perspective. -- John Baldwin
