[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0fc3f574-6243-4c85-a6a7-442dc480c9e7@linux.intel.com>
Date: Wed, 31 Jan 2024 12:53:24 +0100
From: Marcin Szycik <marcin.szycik@...ux.intel.com>
To: Takeru Hayasaka <hayatake396@...il.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Jonathan Corbet <corbet@....net>
Cc: linux-doc@...r.kernel.org, vladimir.oltean@....com,
linux-kernel@...r.kernel.org, laforge@...monks.org,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
mailhol.vincent@...adoo.fr
Subject: Re: [Intel-wired-lan] [PATCH net-next v5] ethtool: ice: Support for
RSS settings to GTP from ethtool
On 31.01.2024 02:37, Takeru Hayasaka wrote:
> This is a patch that enables RSS functionality for GTP packets using ethtool.
>
> A user can include TEID and make RSS work for GTP-U over IPv4 by doing the
> following:`ethtool -N ens3 rx-flow-hash gtpu4 sde`
>
> In addition to gtpu(4|6), we now support gtpc(4|6),gtpc(4|6)t,gtpu(4|6)e,
> gtpu(4|6)u, and gtpu(4|6)d.
>
> gtpc(4|6): Used for GTP-C in IPv4 and IPv6, where the GTP header format does
> not include a TEID.
> gtpc(4|6)t: Used for GTP-C in IPv4 and IPv6, with a GTP header format that
> includes a TEID.
> gtpu(4|6): Used for GTP-U in both IPv4 and IPv6 scenarios.
> gtpu(4|6)e: Used for GTP-U with extended headers in both IPv4 and IPv6.
> gtpu(4|6)u: Used when the PSC (PDU session container) in the GTP-U extended
> header includes Uplink, applicable to both IPv4 and IPv6.
> gtpu(4|6)d: Used when the PSC in the GTP-U extended header includes Downlink,
> for both IPv4 and IPv6.
>
> 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.
> Problematic from a load distribution perspective, especially if there's a bias
> in the terminals connected to a particular base station.This case can be
> solved by using this patch.
LGTM
Reviewed-by: Marcin Szycik <marcin.szycik@...ux.intel.com>
> Signed-off-by: Takeru Hayasaka <hayatake396@...il.com>
> ---
> v2->v3: Based on Harald-san's review, I added documentation and comments to
> ethtool.h and ice.rst.
> v3->v4: Based on Marcin-san's review, I added the missing code for GTPC and
> GTPC_TEID, and revised the documentation and comments.
> v4->v5: Based on Marcin-san's review, I fixed rename and wrong code regarding
> GTPC
[...]
> f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet.
> n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet.
> -
Still removing this line :c
> + e Hash on GTP Packet on TEID (4bytes) of the Rx packet.
>
> Accelerated Receive Flow Steering (aRFS)
> ----------------------------------------
---8<---
Powered by blists - more mailing lists