Hi Jakub san Thank you for your reply! 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
Thank you for your understanding. 2023年10月11日(水) 4:32 Jakub Kicinski <[email protected]>: > On Sun, 8 Oct 2023 07:52:22 +0000 Takeru Hayasaka wrote: > > This is a patch that enables RSS functionality for GTP packets using > > ethtool. > > A user can include her TEID and make RSS work for GTP-U over IPv4 by > > doing the following: > > `ethtool -N ens3 rx-flow-hash gtpu4 sd` > > In addition to gtpu(4|6), we now support gtpc(4|6), gtpu(4|6)e, > > gtpu(4|6)u, and gtpu(4|6)d. > > This is for tunneling, right? IDK much about GTP but we don't have flow > types for other tunneling protos. What makes this one special? >
_______________________________________________ Intel-wired-lan mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
