On 2/3/20 7:00 AM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] 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
