All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Pismenny <borisp@mellanox.com>
To: David Miller <davem@davemloft.net>
Cc: kuba@kernel.org, john.fastabend@gmail.com, daniel@iogearbox.net,
	tariqt@mellanox.com,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] tls: add zerocopy device sendpage
Date: Mon, 13 Jul 2020 10:49:49 +0300	[thread overview]
Message-ID: <5aa3b1d7-ba99-546d-9440-2ffce28b1a11@mellanox.com> (raw)
In-Reply-To: <20200712.153233.370000904740228888.davem@davemloft.net>

On 13/07/2020 1:32, David Miller wrote:
> From: Boris Pismenny <borisp@mellanox.com>
> Date: Sun, 12 Jul 2020 13:44:09 +0300
>
>> This patch adds two configuration knobs to control TLS zerocopy sendfile:
>> 1) socket option named TLS_TX_ZEROCOPY_SENDFILE that enables
>> applications to use zerocopy sendfile on a per-socket basis.
>> 2) global sysctl named tls_zerocopy_sendfile that defines the default
>> for the entire system.
> We already have too many knobs, don't add this until we find that
> it is necessary and that the kernel can't do the optimal thing
> on it's own.

An alternative approach that requires no knobs is to change the
current TLS_DEVICE sendfile flow to skip the copy. It is really
not necessary to copy the data, as the guarantees it provides to
users, namely that users can modify page cache data sent via sendfile
with no error, justifies the performance overhead.
Users that sendfile data from the pagecache while modifying
it cannot reasonably expect data on the other side to be
consistent. TCP sendfile guarantees nothing except that
the TCP checksum is correct. TLS sendfile with copy guarantees
the same, but TLS sendfile zerocopy (with offload) will send
the modified data, and this can trigger an authentication error
on the TLS layer when inconsistent data is received. If the data
is inconsistent, then letting the user know via an error is desirable,
right?

If there are no objections, I'd gladly resubmit it with the approach
described above.

       reply	other threads:[~2020-07-13  7:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1594550649-3097-1-git-send-email-borisp@mellanox.com>
     [not found] ` <20200712.153233.370000904740228888.davem@davemloft.net>
2020-07-13  7:49   ` Boris Pismenny [this message]
2020-07-13 19:05     ` [PATCH] tls: add zerocopy device sendpage David Miller
2020-07-13 22:15       ` Boris Pismenny
2020-07-13 22:59         ` Jakub Kicinski
2020-07-14  7:31           ` Boris Pismenny
2020-07-14 16:23             ` Jakub Kicinski
2020-07-14 20:38             ` David Miller
2020-07-14  1:02         ` David Miller
2020-07-14  7:27           ` Boris Pismenny
2020-07-14 20:42             ` David Miller
2020-07-14 20:56               ` Boris Pismenny
2020-07-12 10:53 Boris Pismenny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5aa3b1d7-ba99-546d-9440-2ffce28b1a11@mellanox.com \
    --to=borisp@mellanox.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tariqt@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.