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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ