netdev - Re: [PATCH iproute2-next] ss: Show zerocopy sendfile status of TLS sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b050eb9a-b627-4efb-8095-d3be52ca3264@nvidia.com>
Date:   Wed, 1 Jun 2022 11:58:22 +0300
From:   Maxim Mikityanskiy <maximmi@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     David Ahern <dsahern@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Tariq Toukan <tariqt@...dia.com>,
        Boris Pismenny <borisp@...dia.com>, netdev@...r.kernel.org
Subject: Re: [PATCH iproute2-next] ss: Show zerocopy sendfile status of TLS
 sockets

On 2022-05-31 22:18, Jakub Kicinski wrote:
> 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.

I suggest mentioning the purpose of this optimization: a huge 
performance boost of up to 2.4 times compared to non-zerocopy device 
offload. See the performance numbers from my commit message:

 > Performance numbers in a single-core test with 24 HTTPS streams on
 > nginx, under 100% CPU load:
 >
 > * non-zerocopy: 33.6 Gbit/s
 > * zerocopy: 79.92 Gbit/s
 >
 > CPU: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz

The rest of the text looks good to me and accurately describes the 
limitations, intended use case and possible consequences. Thanks for 
taking care of the documentation!

> 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.