Received-SPF: pass (google.com: domain of linux-kernel+bounces-44359-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240127140747.905552-1-hayatake396@gmail.com>
 <154f979e-a335-461b-b72e-5e9c54fe940c@linux.intel.com> <CADFiAcJShbgBLXdVgs1vK1jqDFopkRcw-se4b4h0V3Yd60xLVw@mail.gmail.com>
 <92958c7b-7e5f-4e25-819f-4e52f9ffcf7b@linux.intel.com>
In-Reply-To: <92958c7b-7e5f-4e25-819f-4e52f9ffcf7b@linux.intel.com>
From: takeru hayasaka <hayatake396@gmail.com>
Date: Tue, 30 Jan 2024 19:11:26 +0900
Message-ID: <CADFiAc+0G2ncXKDQ+p8aZ98HtfsqNBHoSZVTYhgXUHu+=dof+A@mail.gmail.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next RESENT v3] ethtool: ice:
 Support for RSS settings to GTP from ethtool
To: Marcin Szycik <marcin.szycik@linux.intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>, Tony Nguyen <anthony.l.nguyen@intel.com>, 
	"David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, 
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	linux-doc@vger.kernel.org, vladimir.oltean@nxp.com, 
	linux-kernel@vger.kernel.org, laforge@gnumonks.org, 
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, 
	mailhol.vincent@wanadoo.fr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Marcin-san
Thank you for your comment:)

> The way I understand it now, this patch (and the ethtool one) adds hashin=
g on
> TEID field in GTP* headers. So I wanted to ask why do we have a case (gtp=
c(4|6))
> that doesn't include TEID? Do we hash on other fields in this header?

I understand your question to be asking why it is necessary to have
the option to select gtpc(4|6) for RSS when it doesn't include the
TEID.

When hashing in cases where TEID is not included, it can be done with
the IMSI (telephone number) or the SeqNum of the GTPC in this header.
Essentially, it depends on the implementation, but there is a reason
for differentiation as the context is different between cases where
GTPC includes TEID and those where it does not.

Thanks,
Takeru

2024=E5=B9=B41=E6=9C=8830=E6=97=A5(=E7=81=AB) 18:59 Marcin Szycik <marcin.s=
zycik@linux.intel.com>:
>
>
>
> On 30.01.2024 07:39, takeru hayasaka wrote:
> > Hi Marcin-san
> > Thanks for your review!
> >
> >> Do I understand correctly that all gtpu* include TEID? Maybe write it =
here.
> > Yes, that's correct.
> >
> >> It would be nice to see a link to the patch that added GTP and 'e' fla=
g support
> > to ethtool itself ("ethtool: add support for rx-flow-hash gtp").
> > I will send you the link.
> > The one I sent earlier was outdated, so I've updated it to match this p=
atch.
> > https://lore.kernel.org/netdev/20240130053742.946517-1-hayatake396@gmai=
l.com/
> >
> >> gtpc(4|6) doesn't include TEID, so what is its purpose?
> > In GTPC communication, there is no TEID in the CSR (Create Session Requ=
est).
> > Therefore, there are cases of GTPC that do not include TEID.
>
> The way I understand it now, this patch (and the ethtool one) adds hashin=
g on
> TEID field in GTP* headers. So I wanted to ask why do we have a case (gtp=
c(4|6))
> that doesn't include TEID? Do we hash on other fields in this header?
>
> >
> >> s/TEID(4byte)/TEID (4bytes)/
> >> Also, I think two newlines should remain here.
> > I will correct the TEID notation in the next patch!
>
> Thanks,
> Marcin
>
> ---8<---