Messages in this thread | | | Date | Wed, 18 Oct 2023 10:37:03 -0700 | From | Jakub Kicinski <> | Subject | Re: [PATCH net-next v2] ethtool: ice: Support for RSS settings to GTP from ethtool |
| |
On Wed, 18 Oct 2023 10:53:02 +0900 takeru hayasaka wrote: > 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). > This is quite convenient from a scalability perspective. In fact, in > 5G UPF, the communication is explicitly only on the User plane > (Uplane). > > Therefore, services are expected to receive only GTPU traffic (e.g., > PGW-U, UPF) or only GTPC traffic (e.g., PGW-C). Hence, there arises a > necessity to use only GTPU. > > If we do not distinguish packets into Control/User (C/U) with options > like gtp4|6, I can conceive scenarios where performance tuning becomes > challenging. > For example, in cases where we want to process only the control > communication (GTPC) using Flow Director on specific CPUs, while > processing GTPU on the remaining cores. > In scenarios like IoT, where user communication is minimal but the > volume of devices is vast, the control traffic could substantially > increase. Thus, this might also be possible in reverse. > In short, this pertains to being mindful of CPU core affinity. > > 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. > Regarding Extension Headers and such, I think it would be more > straightforward to handle them implicitly. > > What does everyone else think?
Harald went further and questioned use of the same IP addresses for -U and -C traffic, but even within one endpoint aren't these running on a different port? Can someone reasonably use the same UDP port for both types of traffic?
| |