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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20240911173150.571bf93b@kernel.org>
Date: Wed, 11 Sep 2024 17:31:50 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
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 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...