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.
