Re: [PATCH net-next] ethtool: ice: Support for RSS settings to GTP from ethtool

Thank you for teaching me so much!

quoted

Sorry! My email was blocked because it wasn't sent in plain text mode.
I've made the necessary changes and will resend it.

I got it. I'll do it like that :)
Please let me know if I'm using it incorrectly.

Makes sense, thanks for the extra information. I think it would be
worth adding all of this to the commit message!

of course:)
I got it. I will add this background information when I issue a patch
for the next version.

Regarding the patch - you are only adding flow types, not a new field
(which are defined as RXH_*). If we want to hash on an extra field,
I think we need to specify that field as well?

I've been really struggling with this...
When I read the Intel ICE documentation, it suggests that in RSS, TEID
can be an additional input.
However, I couldn't think of a reason not to include TEID when
enabling RSS for GTP cases.

https://www.intel.com/content/www/us/en/content-details/617015/intel-ethernet-controller-e810-dynamic-device-personalization-ddp-technology-guide.html
(cf. Table 8. Patterns and Input Sets for iavf RSS)

However, for Flow Director, it's clear that you'd want to include the
TEID field. But since I found that someone from Intel has already
configured it to use TEID with Flow Director, I thought maybe we don't
need to add the TEID parameter for now.

https://patchwork.ozlabs.org/project/intel-wired-lan/cover/20210126065206.137422-1-haiyue.wang@intel.com/

If we want to include something other than TEID (e.g., QFI) in Flow
Director, I think it would be better to prepare a new field.

2023年10月11日(水) 11:10 Jakub Kicinski [off-list ref]:

On Wed, 11 Oct 2023 10:56:17 +0900 takeru hayasaka wrote:

quoted

GTP generates a flow that includes an ID called TEID to identify the
tunnel. This tunnel is created for each UE (User Equipment).
By performing RSS based on this flow, it is possible to apply RSS for
each communication unit from the UE.
Without this, RSS would only be effective within the range of IP addresses.
For instance, the PGW can only perform RSS within the IP range of the SGW.
What I'm trying to say is that RSS based solely on IP addresses can be
problematic from a load distribution perspective, especially if
there's a bias in the terminals connected to a particular base
station.
As a reference that discusses a similar topic, please see the link
below(is not RSS, is TEID Flow):
https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-56/Layer-3/Routing/Equal-Cost-Multipath-Load-Sharing/#gtp-hashing

Makes sense, thanks for the extra information. I think it would be
worth adding all of this to the commit message!

Regarding the patch - you are only adding flow types, not a new field
(which are defined as RXH_*). If we want to hash on an extra field,
I think we need to specify that field as well?

quoted

Thank you for your understanding.
---
Sorry! My email was blocked because it wasn't sent in plain text mode.
I've made the necessary changes and will resend it.

No worries! Additional request - in the future please prefer the
bottom-posting or interleaved style of replies:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style