From owner-freebsd-current@freebsd.org Fri Feb 26 17:53:05 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BEC4A548B2B for ; Fri, 26 Feb 2021 17:53:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DnHLn510Cz4dRX for ; Fri, 26 Feb 2021 17:53:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id h22so9819742otr.6 for ; Fri, 26 Feb 2021 09:53:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Smy6QA+iW6pkVbJje3A1AD/i9BSzpe1zXnEwNJ92qCQ=; b=fUbUFIze4Mka5Otqcb6FazRZSyaSpBs4XotN/b2PudifbI/oE7z0LPLDidcGlVvu7n pszlAMBlsyP0bDtBNgV47W/jbLSyHqighjRrvu6iwegql94bDZjjVIHDyFiWOyUuZ15d lU572QeDSfl7y4YirrMFfSIIPsWUVgaUiw/E8UXSeQysesT9mAnM09kvMbrWvQHyDKde aZdFi97c5MZR66ydwHnX9okouijmyCp0wzbI/Ryke5150iqWdsNlUbeQVRXWDK7VvGAg vhTVxHj7Y6h81Cv9g6lDw18pe0Yrqitw9T5lBy68vPkntpGJ9LNRtVf63953BC7G3D/Z 329g== X-Gm-Message-State: AOAM530yj83dQlBBiCRJ/KLdTTsGyUhp2rkyAKhDLIGyDMWR44GjW7fi w/dHFPDqRG/0ZSdDbuvOBKaA/AlBboZuxTpjYkzl/N6K+u8= X-Google-Smtp-Source: ABdhPJzbAYnSwcczKeI5USkB12hIzvBsLVfiXvrnG3/bnyqmU7Yorro2HqxpB1E2cn99L+Fj8t/b93Pihdut15zFbn8= X-Received: by 2002:a9d:3642:: with SMTP id w60mr3292900otb.18.1614361984504; Fri, 26 Feb 2021 09:53:04 -0800 (PST) MIME-Version: 1.0 References: <202102261624.11QGOnq2030932@gndrsh.dnsmgr.net> In-Reply-To: <202102261624.11QGOnq2030932@gndrsh.dnsmgr.net> From: Alan Somers Date: Fri, 26 Feb 2021 10:52:53 -0700 Message-ID: Subject: Re: KTLS with zfs recv To: "Rodney W. Grimes" Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4DnHLn510Cz4dRX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 17:53:05 -0000 On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < freebsd-rwg@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@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?