Dear Takeru, Jakub and list,
On Wed, Oct 18, 2023 at 10:53:02AM +0900, takeru hayasaka wrote:
Let's forget about capabilities of Intel NICs for now - can you as a user think of practical use cases where we'd want to turn on hashing based on TEID for, e.g. gtpu6 and not gtpc6?
of course! There are clearly cases where we would want to use gtpu4|6 instead of gtpc4|6.
For instance, there are PGWs that have the capability to separate the termination of communication of 4G LTE users into Control and User planes (C/U).
I would argue it is the standard case in any PGW (or SMF+UPF) to process GTP-C differently than GTP-U. That's what the entire CUPS (control/user plane split) architecture is meant for.
Now the question is how does one implement that? As the related signaling protocols all allow to specify different IP addresses for GTPv1/v2-C (v1 for 2G/3G and v2 for 4G) and GTPv1-U (v1 used everywhere) it is always possible to use separate IP addresses for control and user plane. It's even normal that a single GTP-C instance (on one IP) manages multiple GTP-U instances on other IP-addresses. Those IPs are then handled by completely different physical servers/systems/VMs/...
So only in case the user intentionally configures their network to use the same IP address for GTP-C and GTP-U traffic one will need to start distinguishing GTP-C and GTP-U on one host/NIC with the RSS mechanism: Steer the GTP-C traffic to the control plane instance on one CPU and spread the GTP-U traffic via hash function to multiple other queues/CPUs. I personally think it's short-sighted to use identical IPs for control and user plane, as it means you can never scale out to multiple machines without introducing some kind of dedicated load balancer in front. But assuming some people still want to do it that way: Yes, then you need the feature to split GTP-C form GTP-U via RSS to scale well.
What I'm somehwat more wondering about is the usability to load-balance GTP-C traffic over multiple queues/cores. As stated earlier, that's just signaling.
If we were to propose again, setting aside considerations specific to Intel, I believe, considering the users of ethtool, the smallest units should be gtpu4|6 and gtpc4|6.
agreed. Though I'm not entirely sure one would usually want to treat v4 different from v6. I'd assume they would usually both follow the same RSS scheme?
Regarding Extension Headers and such, I think it would be more straightforward to handle them implicitly.
I would also agree to that.