Date: Fri, 26 Feb 2021 08:24:49 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: KTLS with zfs recv Message-ID: <202102261624.11QGOnq2030932@gndrsh.dnsmgr.net> In-Reply-To: <CAOtMX2jMADS3vWCeXPHSfVCm12NoPkEw5--AHcnWP0anX0jqEQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202102261624.11QGOnq2030932>