Re: KTLS with zfs recv

From: Warner Losh <imp_at_bsdimp.com>
Date: Fri, 26 Feb 2021 11:53:03 -0700
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...

Warner
Received 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