netdev - Re: [PATCH net-next] ethtool: ice: Support for RSS settings to GTP from ethtool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231010191019.12fb7071@kernel.org>
Date: Tue, 10 Oct 2023 19:10:19 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: takeru hayasaka <hayatake396@...il.com>
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

On Wed, 11 Oct 2023 10:56:17 +0900 takeru hayasaka wrote:
> 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

Makes sense, thanks for the extra information. I think it would be
worth adding all of this to the commit message!

Regarding the patch - you are only adding flow types, not a new field 
(which are defined as RXH_*). If we want to hash on an extra field, 
I think we need to specify that field as well?

> 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.

No worries! Additional request - in the future please prefer the
bottom-posting or interleaved style of replies:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style