From: Jakub Kicinski <kuba@kernel.org>
To: Maxim Mikityanskiy <maximmi@nvidia.com>
Cc: David Ahern <dsahern@gmail.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Tariq Toukan <tariqt@nvidia.com>,
Boris Pismenny <borisp@nvidia.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH iproute2-next] ss: Show zerocopy sendfile status of TLS sockets
Date: Tue, 31 May 2022 12:18:29 -0700 [thread overview]
Message-ID: <20220531121829.01d02463@kernel.org> (raw)
In-Reply-To: <20220530111745.7679b8c4@kernel.org>
On Mon, 30 May 2022 11:17:45 -0700 Jakub Kicinski wrote:
> Also please send a patch to Documentation/, I forgot about that.
Actually let me take care of that on my own, I have some optimizations
to add, saves me a rebase ;)
Does this sound good?
Optional optimizations
----------------------
There are certain condition-specific optimizations the TLS ULP can make,
if requested. Those optimizations are either not universally beneficial
or may impact correctness, hence they require an opt-in.
All options are set per-socket using setsockopt(), and their
state can be checked using getsockopt() and via socket diag (``ss``).
TLS_INFO_ZC_SENDFILE
~~~~~~~~~~~~~~~~~~~~
For device offload only. Allow sendfile() data to be transmitted directly
to the NIC without making an in-kernel copy. This allows true zero-copy
behavior when device offload is enabled.
The application must make sure that the data is not modified between being
submitted and transmission completing. In other words this is mostly
applicable if the data sent on a socket via sendfile() is read-only.
Modifying the data may result in different versions of the data being used
for the original TCP transmission and TCP retransmissions. To the receiver
this will look like TLS records had been tampered with and will result
in record authentication failures.
next prev parent reply other threads:[~2022-05-31 19:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-30 14:14 [PATCH iproute2-next] ss: Show zerocopy sendfile status of TLS sockets Maxim Mikityanskiy
2022-05-30 16:24 ` Stephen Hemminger
2022-05-31 7:00 ` Maxim Mikityanskiy
2022-05-31 14:22 ` David Ahern
2022-05-30 18:17 ` Jakub Kicinski
2022-05-31 19:18 ` Jakub Kicinski [this message]
2022-05-31 19:20 ` Jakub Kicinski
2022-06-01 8:58 ` Maxim Mikityanskiy
2022-06-01 15:42 ` Jakub Kicinski
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=20220531121829.01d02463@kernel.org \
--to=kuba@kernel.org \
--cc=borisp@nvidia.com \
--cc=dsahern@gmail.com \
--cc=maximmi@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=tariqt@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).