[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADFiAcKF08osdvd4EiXSR1YJ22TXrMu3b7ujkMTwAsEE8jzgOw@mail.gmail.com>
Date: Wed, 11 Oct 2023 10:56:17 +0900
From: takeru hayasaka <hayatake396@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Jesse Brandeburg <jesse.brandeburg@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] ethtool: ice: Support for RSS settings to GTP
from ethtool
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.
---
Sorry! My email was blocked because it wasn't sent in plain text mode.
I've made the necessary changes and will resend it.
2023年10月11日(水) 4:32 Jakub Kicinski <kuba@...nel.org>:
>
> 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?
Powered by blists - more mailing lists