From: Jakub Kicinski <kuba@kernel.org>
To: Maxim Mikityanskiy <maximmi@nvidia.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Daniel Borkmann <daniel@iogearbox.net>,
Paolo Abeni <pabeni@redhat.com>,
Boris Pismenny <borisp@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
"Saeed Mahameed" <saeedm@nvidia.com>,
Gal Pressman <gal@nvidia.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next v2] tls: Add opt-in zerocopy mode of sendfile()
Date: Thu, 12 May 2022 16:34:58 -0700 [thread overview]
Message-ID: <20220512163458.31ae2d13@kernel.org> (raw)
In-Reply-To: <20220511121525.624059-1-maximmi@nvidia.com>
On Wed, 11 May 2022 15:15:25 +0300 Maxim Mikityanskiy wrote:
> TLS device offload copies sendfile data to a bounce buffer before
> transmitting. It allows to maintain the valid MAC on TLS records when
> the file contents change and a part of TLS record has to be
> retransmitted on TCP level.
>
> In many common use cases (like serving static files over HTTPS) the file
> contents are not changed on the fly. In many use cases breaking the
> connection is totally acceptable if the file is changed during
> transmission, because it would be received corrupted in any case.
>
> This commit allows to optimize performance for such use cases to
> providing a new optional mode of TLS sendfile(), in which the extra copy
> is skipped. Removing this copy improves performance significantly, as
> TLS and TCP sendfile perform the same operations, and the only overhead
> is TLS header/trailer insertion.
>
> The new mode can only be enabled with the new socket option named
> TLS_TX_ZEROCOPY_SENDFILE on per-socket basis. It preserves backwards
> compatibility with existing applications that rely on the copying
> behavior.
>
> The new mode is safe, meaning that unsolicited modifications of the file
> being sent can't break integrity of the kernel. The worst thing that can
> happen is sending a corrupted TLS record, which is in any case not
> forbidden when using regular TCP sockets.
>
> Sockets other than TLS device offload are not affected by the new socket
> option.
What about the reporting via sock diag? Am I misremembering something?
next prev parent reply other threads:[~2022-05-12 23:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-11 12:15 [PATCH net-next v2] tls: Add opt-in zerocopy mode of sendfile() Maxim Mikityanskiy
2022-05-12 23:34 ` Jakub Kicinski [this message]
2022-05-13 7:57 ` Maxim Mikityanskiy
2022-05-13 16:02 ` 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=20220512163458.31ae2d13@kernel.org \
--to=kuba@kernel.org \
--cc=borisp@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=gal@nvidia.com \
--cc=maximmi@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--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 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.