netdev - Re: [PATCH net-next v2 3/4] ethtool: Add support for configuring tcp-data-split-thresh

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 for Android: free password hash cracker in your pocket

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

Message-ID: <785a6cbe-da9c-4d76-807a-54d0007745a9@intel.com>
Date: Thu, 12 Sep 2024 10:42:01 -0500
From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Taehee Yoo <ap420073@...il.com>, <davem@...emloft.net>,
	<pabeni@...hat.com>, <edumazet@...gle.com>, <corbet@....net>,
	<michael.chan@...adcom.com>, <netdev@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <ecree.xilinx@...il.com>,
	<przemyslaw.kitszel@...el.com>, <andrew@...n.ch>, <hkallweit1@...il.com>,
	<kory.maincent@...tlin.com>, <ahmed.zaki@...el.com>,
	<paul.greenwalt@...el.com>, <rrameshbabu@...dia.com>, <idosch@...dia.com>,
	<maxime.chevallier@...tlin.com>, <danieller@...dia.com>,
	<aleksander.lobakin@...el.com>
Subject: Re: [PATCH net-next v2 3/4] ethtool: Add support for configuring
 tcp-data-split-thresh



On 9/11/2024 7:31 PM, Jakub Kicinski wrote:
> On Wed, 11 Sep 2024 11:51:42 -0500 Samudrala, Sridhar wrote:
>> On 9/11/2024 9:55 AM, Taehee Yoo wrote:
>>> The tcp-data-split-thresh option configures the threshold value of
>>> the tcp-data-split.
>>> If a received packet size is larger than this threshold value, a packet
>>> will be split into header and payload.
>>> The header indicates TCP header, but it depends on driver spec.
>>> The bnxt_en driver supports HDS(Header-Data-Split) configuration at
>>> FW level, affecting TCP and UDP too.
>>> So, like the tcp-data-split option, If tcp-data-split-thresh is set,
>>> it affects UDP and TCP packets.
>>
>> What about non-tcp/udp packets? Are they are not split?
>> It is possible that they may be split at L3 payload for IP/IPV6 packets
>> and L2 payload for non-ip packets.
>> So instead of calling this option as tcp-data-split-thresh, can we call
>> it header-data-split-thresh?
> 
> This makes sense.
> 
>>> The tcp-data-split-thresh has a dependency, that is tcp-data-split
>>> option. This threshold value can be get/set only when tcp-data-split
>>> option is enabled.
>>
>> Even the existing 'tcp-data-split' name is misleading. Not sure if it
>> will be possible to change this now.
> 
> It's not misleading, unless you think that it is something else than
> it is.
> 
>    ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` indicates whether the device
>    is usable with page-flipping TCP zero-copy receive
>    (``getsockopt(TCP_ZEROCOPY_RECEIVE)``). If enabled the device is
>    configured to place frame headers and data into separate buffers.
>    The device configuration must make it possible to receive full memory
>    pages of data, for example because MTU is high enough or through
>    HW-GRO.
> 
> If you use this for more than what's stated in the documentation
> that's on you. More granular "what gets split and what doesn't"
> control should probably go into an API akin to how we configure
> RSS hashing fields. But I'm not sure anyone actually cares about
> other protocols at this stage, so...

OK, as the the main use case for header split is tcp zero copy receive 
at this time and the documentation is also explicitly calling out TCP, 
this should be fine and we can introduce API to configure header split 
behavior for non-tcp protocols in future if required.