On Fri, Feb 26, 2021 at 11:16 AM Rodney W. Grimes < freebsd-rwg_at_gndrsh.dnsmgr.net> wrote: > > On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < > > freebsd-rwg_at_gndrsh.dnsmgr.net> wrote: > > > > > > My understanding is that KTLS works very well with OpenSSL for > sending, > > > but > > > > not as well for receiving, because there's nothing like a recvfile > > > > syscall. However, it works great for both send and receive with NFS, > > > where > > > > all the data remains in the kernel. What about zfs recv? A very > common > > > > pattern is for an application to read from an SSL socket and then > pipe > > > the > > > > data to zfs recv. For example, zrepl does that. Could zfs recv > instead > > > > read directly from the KTLS socket, bypassing userspace? That could > > > > potentially save a _lot_ of cycles for a _lot_ of people. > > > > > > I did some patches and a short presentation at BSDCan that basically > > > shoves the whole zfs send and zfs recv process into the kernel, ie > > > it opens the sockets up, makes the connections, then the socket > > > is passed into the kernel(s) and it all runs in kernel mode. > > > > > > > > > > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf > > > > > > A few things need fixed like reversing who does the listen for > > > security reasons, but this feature is probably ready for prime > > > time. > > > > > > > -Alan > > > > > > -- > > > Rod Grimes > > > rgrimes_at_freebsd.org > > > > > > That looks potentially useful, but it doesn't use encryption. Would it > > work if the socket had been opened by openssl with ktls? > > Yes, it should. Internally the zfs send and recv code just does reads > and writes to the socket, so what ever you setup for "connected" sockets > should work. > Yea, KTLS generally wants userland to do the initial negotiation and share the connection state before doing the bulk encryption in the kernel... WarnerReceived on Fri Feb 26 2021 - 17:53:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC