diff mbox series

[net-next,v8,1/2] ethtool: Add GTP RSS hash options to ethtool.h

Message ID 20240212020403.1639030-1-hayatake396@gmail.com (mailing list archive)
State Not Applicable
Delegated to: Netdev Maintainers
Headers show
Series [net-next,v8,1/2] ethtool: Add GTP RSS hash options to ethtool.h | expand

Checks

Context Check Description
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for net-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 2750 this patch: 2750
netdev/build_tools success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers success CCed 3 of 3 maintainers
netdev/build_clang success Errors and warnings before: 1087 this patch: 1087
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 2946 this patch: 2946
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 60 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
netdev/contest success net-next-2024-02-16--06-00 (tests: 1443)

Commit Message

Takeru Hayasaka Feb. 12, 2024, 2:04 a.m. UTC
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.

Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.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
v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary
blank lines.Minor fixes.
v6->v7 Based on Jakub-san's review, Split the patch.
v7->v8: There are no code changes. I've resent the patch, including Marcin-san's
patch, because PatchWork did not interpret the patch correctly.Simon-san told
me. Thanks.
 include/uapi/linux/ethtool.h | 48 ++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

Comments

Takeru Hayasaka Feb. 15, 2024, 8:44 a.m. UTC | #1
Hi Jakub-san

As previously advised, the patch has been divided.
I apologize for the inconvenience, but I would appreciate it if you
could take the time to review the patch.
I understand you may be busy, but your confirmation would be greatly
appreciated.

Thanks
Takeru

2024年2月12日(月) 11:04 Takeru Hayasaka <hayatake396@gmail.com>:
>
> 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.
>
> Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.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
> v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary
> blank lines.Minor fixes.
> v6->v7 Based on Jakub-san's review, Split the patch.
> v7->v8: There are no code changes. I've resent the patch, including Marcin-san's
> patch, because PatchWork did not interpret the patch correctly.Simon-san told
> me. Thanks.
>  include/uapi/linux/ethtool.h | 48 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>
> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> index 06ef6b78b7de..11fc18988bc2 100644
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
> @@ -2023,6 +2023,53 @@ static inline int ethtool_validate_duplex(__u8 duplex)
>  #define        IPV4_FLOW       0x10    /* hash only */
>  #define        IPV6_FLOW       0x11    /* hash only */
>  #define        ETHER_FLOW      0x12    /* spec only (ether_spec) */
> +
> +/* Used for GTP-U IPv4 and IPv6.
> + * The format of GTP packets only includes
> + * elements such as TEID and GTP version.
> + * It is primarily intended for data communication of the UE.
> + */
> +#define GTPU_V4_FLOW 0x13      /* hash only */
> +#define GTPU_V6_FLOW 0x14      /* hash only */
> +
> +/* Use for GTP-C IPv4 and v6.
> + * The format of these GTP packets does not include TEID.
> + * Primarily expected to be used for communication
> + * to create sessions for UE data communication,
> + * commonly referred to as CSR (Create Session Request).
> + */
> +#define GTPC_V4_FLOW 0x15      /* hash only */
> +#define GTPC_V6_FLOW 0x16      /* hash only */
> +
> +/* Use for GTP-C IPv4 and v6.
> + * Unlike GTPC_V4_FLOW, the format of these GTP packets includes TEID.
> + * After session creation, it becomes this packet.
> + * This is mainly used for requests to realize UE handover.
> + */
> +#define GTPC_TEID_V4_FLOW 0x17 /* hash only */
> +#define GTPC_TEID_V6_FLOW 0x18 /* hash only */
> +
> +/* Use for GTP-U and extended headers for the PSC (PDU Session Container).
> + * The format of these GTP packets includes TEID and QFI.
> + * In 5G communication using UPF (User Plane Function),
> + * data communication with this extended header is performed.
> + */
> +#define GTPU_EH_V4_FLOW 0x19   /* hash only */
> +#define GTPU_EH_V6_FLOW 0x1a   /* hash only */
> +
> +/* Use for GTP-U IPv4 and v6 PSC (PDU Session Container) extended headers.
> + * This differs from GTPU_EH_V(4|6)_FLOW in that it is distinguished by
> + * UL/DL included in the PSC.
> + * There are differences in the data included based on Downlink/Uplink,
> + * and can be used to distinguish packets.
> + * The functions described so far are useful when you want to
> + * handle communication from the mobile network in UPF, PGW, etc.
> + */
> +#define GTPU_UL_V4_FLOW 0x1b   /* hash only */
> +#define GTPU_UL_V6_FLOW 0x1c   /* hash only */
> +#define GTPU_DL_V4_FLOW 0x1d   /* hash only */
> +#define GTPU_DL_V6_FLOW 0x1e   /* hash only */
> +
>  /* Flag to enable additional fields in struct ethtool_rx_flow_spec */
>  #define        FLOW_EXT        0x80000000
>  #define        FLOW_MAC_EXT    0x40000000
> @@ -2037,6 +2084,7 @@ static inline int ethtool_validate_duplex(__u8 duplex)
>  #define        RXH_IP_DST      (1 << 5)
>  #define        RXH_L4_B_0_1    (1 << 6) /* src port in case of TCP/UDP/SCTP */
>  #define        RXH_L4_B_2_3    (1 << 7) /* dst port in case of TCP/UDP/SCTP */
> +#define        RXH_GTP_TEID    (1 << 8) /* teid in case of GTP */
>  #define        RXH_DISCARD     (1 << 31)
>
>  #define        RX_CLS_FLOW_DISC        0xffffffffffffffffULL
> --
> 2.34.1
>
Paolo Abeni Feb. 15, 2024, 10:26 a.m. UTC | #2
Hi,

On Thu, 2024-02-15 at 17:44 +0900, Takeru Hayasaka wrote:
> As previously advised, the patch has been divided.
> I apologize for the inconvenience, but I would appreciate it if you
> could take the time to review the patch.
> I understand you may be busy, but your confirmation would be greatly
> appreciated.

The series LGTM. I *think* the series should go first in the intel
tree, so it can be tested on the relevant H/W. @Tony: do you agree?

Thanks,

Paolo
Tony Nguyen Feb. 15, 2024, 3:56 p.m. UTC | #3
On 2/15/24 2:26 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> Hi,
> 
> On Thu, 2024-02-15 at 17:44 +0900, Takeru Hayasaka wrote:
> > As previously advised, the patch has been divided.
> > I apologize for the inconvenience, but I would appreciate it if you
> > could take the time to review the patch.
> > I understand you may be busy, but your confirmation would be greatly
> > appreciated.
> 
> The series LGTM. I *think* the series should go first in the intel
> tree, so it can be tested on the relevant H/W. @Tony: do you agree?

I agree. I think it would make sense for this to go through IWL.

Thanks,
Tony

> Thanks,
> 
> Paolo
> 
>
Takeru Hayasaka Feb. 16, 2024, 2:14 p.m. UTC | #4
Hi Tony-san and Paolo-san!

> > The series LGTM. I *think* the series should go first in the intel

Thank you both for picking up on the topic!

> I agree. I think it would make sense for this to go through IWL.

I understand. So, it means that it will go through the IWL branch and
then through net-next.
Is there any assistance I can provide to facilitate this process?

Thanks,
Takeru
Tony Nguyen Feb. 16, 2024, 9:14 p.m. UTC | #5
On 2/16/2024 6:14 AM, Takeru Hayasaka wrote:
> Hi Tony-san and Paolo-san!
> 
>>> The series LGTM. I *think* the series should go first in the intel
> 
> Thank you both for picking up on the topic!
> 
>> I agree. I think it would make sense for this to go through IWL.
> 
> I understand. So, it means that it will go through the IWL branch and
> then through net-next.

Yes, it will go through next-queue/dev-queue and then to net-next
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git/

> Is there any assistance I can provide to facilitate this process?

Everything is good for now. If we have issues or questions we will reach 
out to you.

Thanks,
Tony

> Thanks,
> Takeru
Takeru Hayasaka Feb. 17, 2024, 6:18 a.m. UTC | #6
Hi Tony-san

Thanks for your reply!
> Everything is good for now. If we have issues or questions we will reach
> out to you.

Okay. Let me know if there's anything I can help with:)

Thanks
Takeru
Pucha, HimasekharX Reddy March 1, 2024, 6:01 p.m. UTC | #7
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Takeru Hayasaka
> Sent: Monday, February 12, 2024 7:34 AM
> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <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>
> Cc: linux-doc@vger.kernel.org; vladimir.oltean@nxp.com; linux-kernel@vger.kernel.org; laforge@gnumonks.org; Marcin Szycik <marcin.szycik@linux.intel.com>; intel-wired-lan@lists.osuosl.org; Takeru Hayasaka <hayatake396@gmail.com>; netdev@vger.kernel.org; mailhol.vincent@wanadoo.fr
> Subject: [Intel-wired-lan] [PATCH net-next v8 1/2] ethtool: Add GTP RSS hash options to ethtool.h
>
> 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.
>
> Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.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
> v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary
> blank lines.Minor fixes.
> v6->v7 Based on Jakub-san's review, Split the patch.
> v7->v8: There are no code changes. I've resent the patch, including Marcin-san's
> patch, because PatchWork did not interpret the patch correctly.Simon-san told
> me. Thanks.
 > include/uapi/linux/ethtool.h | 48 ++++++++++++++++++++++++++++++++++++
 > 1 file changed, 48 insertions(+)
>

Hi Takeru Hayasaka,

Functionality wise its working fine. But the ethtool part (tab complete doesn't show GTP) 

Please find below logs.

[root@os-delivery ~]# ethtool -N eth4 rx-flow-hash
ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
[root@os-delivery ~]# ethtool -N eth4 rx-flow-hash
ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
[root@os-delivery ~]# ethtool -N eth4 rx-flow-hash gtpu6e sdfn
[root@os-delivery ~]# ethtool -N eth4 rx-flow-hash gtpu6u sdfn
[root@os-delivery ~]# ethtool -N eth4 rx-flow-hash gtpu4u sdfn
[root@os-delivery ~]# ethtool -N eth4 rx-flow-hash gtpu4d sdfn
[root@os-delivery ~]# ethtool -N eth4 rx-flow-hash gtpu6d sdfn
Takeru Hayasaka March 5, 2024, 3:42 a.m. UTC | #8
Hi Himasekhar Reddy-san

> Functionality wise its working fine. But the ethtool part (tab complete doesn't show GTP)

I forgot to add the tab completion feature! Thank you for the good
points. I've added it again in this version's patch.
https://lore.kernel.org/all/20240305033555.524741-1-hayatake396@gmail.com/

Takeru
Pucha, HimasekharX Reddy March 5, 2024, 4:28 a.m. UTC | #9
>-----Original Message-----
> From: Takeru Hayasaka <hayatake396@gmail.com> 
> Sent: Tuesday, March 5, 2024 9:12 AM
> To: Pucha, HimasekharX Reddy <himasekharx.reddy.pucha@intel.com>
> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <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; Marcin Szycik <marcin.szycik@linux.intel.com>; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; mailhol.vincent@wanadoo.fr
> Subject: Re: [Intel-wired-lan] [PATCH net-next v8 1/2] ethtool: Add GTP RSS hash options to ethtool.h
>
> Hi Himasekhar Reddy-san
>
> > Functionality wise its working fine. But the ethtool part (tab complete doesn't show GTP)
>
> I forgot to add the tab completion feature! Thank you for the good
> points. I've added it again in this version's patch.
> https://lore.kernel.org/all/20240305033555.524741-1-hayatake396@gmail.com/
>
> Takeru
>

After added the above v4 patch able to to see tab completion for flow-type but not rx-flow-hash. Please find below logs.

# ethtool -N eth4 rx-flow-hash
ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
# ethtool -N eth4 rx-flow-hash
ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
# ethtool -N eth4 flow-type
ah4     esp4    ether   gtpc4t  gtpc6t  gtpu4d  gtpu4u  gtpu6d  gtpu6u  ip6     sctp6   tcp6    udp6
ah6     esp6    gtpc4   gtpc6   gtpu4   gtpu4e  gtpu6   gtpu6e  ip4     sctp4   tcp4    udp4
Takeru Hayasaka March 5, 2024, 7:47 a.m. UTC | #10
Hi Himasekhar Reddy-san

> After added the above v4 patch able to to see tab completion for flow-type but not rx-flow-hash. Please find below logs.

Sorry. I submitted a code with the conditions reversed. I have
resubmitted it, so could you please check it again?
https://lore.kernel.org/all/20240305074350.533622-1-hayatake396@gmail.com/

Takeru

2024年3月5日(火) 13:28 Pucha, HimasekharX Reddy <himasekharx.reddy.pucha@intel.com>:
>
> >-----Original Message-----
> > From: Takeru Hayasaka <hayatake396@gmail.com>
> > Sent: Tuesday, March 5, 2024 9:12 AM
> > To: Pucha, HimasekharX Reddy <himasekharx.reddy.pucha@intel.com>
> > Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <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; Marcin Szycik <marcin.szycik@linux.intel.com>; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; mailhol.vincent@wanadoo.fr
> > Subject: Re: [Intel-wired-lan] [PATCH net-next v8 1/2] ethtool: Add GTP RSS hash options to ethtool.h
> >
> > Hi Himasekhar Reddy-san
> >
> > > Functionality wise its working fine. But the ethtool part (tab complete doesn't show GTP)
> >
> > I forgot to add the tab completion feature! Thank you for the good
> > points. I've added it again in this version's patch.
> > https://lore.kernel.org/all/20240305033555.524741-1-hayatake396@gmail.com/
> >
> > Takeru
> >
>
> After added the above v4 patch able to to see tab completion for flow-type but not rx-flow-hash. Please find below logs.
>
> # ethtool -N eth4 rx-flow-hash
> ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
> # ethtool -N eth4 rx-flow-hash
> ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
> # ethtool -N eth4 flow-type
> ah4     esp4    ether   gtpc4t  gtpc6t  gtpu4d  gtpu4u  gtpu6d  gtpu6u  ip6     sctp6   tcp6    udp6
> ah6     esp6    gtpc4   gtpc6   gtpu4   gtpu4e  gtpu6   gtpu6e  ip4     sctp4   tcp4    udp4
>
Pucha, HimasekharX Reddy March 5, 2024, 9:31 a.m. UTC | #11
>-----Original Message-----
> From: Takeru Hayasaka <hayatake396@gmail.com> 
> Sent: Tuesday, March 5, 2024 1:18 PM
> To: Pucha, HimasekharX Reddy <himasekharx.reddy.pucha@intel.com>
> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <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; Marcin Szycik <marcin.szycik@linux.intel.com>; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; mailhol.vincent@wanadoo.fr
> Subject: Re: [Intel-wired-lan] [PATCH net-next v8 1/2] ethtool: Add GTP RSS hash options to ethtool.h
>
> Hi Himasekhar Reddy-san
>
> > After added the above v4 patch able to to see tab completion for flow-type but not rx-flow-hash. Please find below logs.
>
> Sorry. I submitted a code with the conditions reversed. I have
> resubmitted it, so could you please check it again?
> https://lore.kernel.org/all/20240305074350.533622-1-hayatake396@gmail.com/
>
> Takeru
>
Hi Takeru,

Its working fine with V5 patch.

# ./ethtool -N eth4 flow-type
ah4    ah6    esp4   esp6   ether  ip4    ip6    sctp4  sctp6  tcp4   tcp6   udp4   udp6
# ./ethtool -N eth4 rx-flow-hash
ah4     esp4    ether   gtpc4t  gtpc6t  gtpu4d  gtpu4u  gtpu6d  gtpu6u  sctp6   tcp6    udp6
ah6     esp6    gtpc4   gtpc6   gtpu4   gtpu4e  gtpu6   gtpu6e  sctp4   tcp4    udp4
# ./ethtool -N eth4 rx-flow-hash gtpc6t
d  e  f  m  n  r  s  t  v
# ./ethtool -N eth4 rx-flow-hash gtpc6t
d  e  f  m  n  r  s  t  v
# ./ethtool -N eth4 rx-flow-hash gtpc6t sde
# ./ethtool -N eth4 rx-flow-hash gtpc6t stv


> 2024年3月5日(火) 13:28 Pucha, HimasekharX Reddy <himasekharx.reddy.pucha@intel.com>:
>
> >-----Original Message-----
> > From: Takeru Hayasaka <hayatake396@gmail.com>
> > Sent: Tuesday, March 5, 2024 9:12 AM
> > To: Pucha, HimasekharX Reddy <himasekharx.reddy.pucha@intel.com>
> > Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <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; Marcin Szycik <marcin.szycik@linux.intel.com>; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; mailhol.vincent@wanadoo.fr
> > Subject: Re: [Intel-wired-lan] [PATCH net-next v8 1/2] ethtool: Add GTP RSS hash options to ethtool.h
> >
> > Hi Himasekhar Reddy-san
> >
> > > Functionality wise its working fine. But the ethtool part (tab complete doesn't show GTP)
> >
> > I forgot to add the tab completion feature! Thank you for the good
> > points. I've added it again in this version's patch.
> > https://lore.kernel.org/all/20240305033555.524741-1-hayatake396@gmail.com/
> >
> > Takeru
> >
>
> After added the above v4 patch able to to see tab completion for flow-type but not rx-flow-hash. Please find below logs.
>
> # ethtool -N eth4 rx-flow-hash
> ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
> # ethtool -N eth4 rx-flow-hash
> ah4    ah6    esp4   esp6   ether  sctp4  sctp6  tcp4   tcp6   udp4   udp6
> # ethtool -N eth4 flow-type
> ah4     esp4    ether   gtpc4t  gtpc6t  gtpu4d  gtpu4u  gtpu6d  gtpu6u  ip6     sctp6   tcp6    udp6
> ah6     esp6    gtpc4   gtpc6   gtpu4   gtpu4e  gtpu6   gtpu6e  ip4     sctp4   tcp4    udp4
>
Pucha, HimasekharX Reddy March 5, 2024, 2:49 p.m. UTC | #12
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Takeru Hayasaka
> Sent: Monday, February 12, 2024 7:34 AM
> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <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>
> Cc: linux-doc@vger.kernel.org; vladimir.oltean@nxp.com; linux-kernel@vger.kernel.org; laforge@gnumonks.org; Marcin Szycik <marcin.szycik@linux.intel.com>; intel-wired-lan@lists.osuosl.org; Takeru Hayasaka <hayatake396@gmail.com>; netdev@vger.kernel.org; mailhol.vincent@wanadoo.fr
> Subject: [Intel-wired-lan] [PATCH net-next v8 1/2] ethtool: Add GTP RSS hash options to ethtool.h
>
> 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.
>
> Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.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
> v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary
> blank lines.Minor fixes.
> v6->v7 Based on Jakub-san's review, Split the patch.
> v7->v8: There are no code changes. I've resent the patch, including Marcin-san's
> patch, because PatchWork did not interpret the patch correctly.Simon-san told
> me. Thanks.
> include/uapi/linux/ethtool.h | 48 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>

Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
diff mbox series

Patch

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 06ef6b78b7de..11fc18988bc2 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -2023,6 +2023,53 @@  static inline int ethtool_validate_duplex(__u8 duplex)
 #define	IPV4_FLOW	0x10	/* hash only */
 #define	IPV6_FLOW	0x11	/* hash only */
 #define	ETHER_FLOW	0x12	/* spec only (ether_spec) */
+
+/* Used for GTP-U IPv4 and IPv6.
+ * The format of GTP packets only includes
+ * elements such as TEID and GTP version.
+ * It is primarily intended for data communication of the UE.
+ */
+#define GTPU_V4_FLOW 0x13	/* hash only */
+#define GTPU_V6_FLOW 0x14	/* hash only */
+
+/* Use for GTP-C IPv4 and v6.
+ * The format of these GTP packets does not include TEID.
+ * Primarily expected to be used for communication
+ * to create sessions for UE data communication,
+ * commonly referred to as CSR (Create Session Request).
+ */
+#define GTPC_V4_FLOW 0x15	/* hash only */
+#define GTPC_V6_FLOW 0x16	/* hash only */
+
+/* Use for GTP-C IPv4 and v6.
+ * Unlike GTPC_V4_FLOW, the format of these GTP packets includes TEID.
+ * After session creation, it becomes this packet.
+ * This is mainly used for requests to realize UE handover.
+ */
+#define GTPC_TEID_V4_FLOW 0x17	/* hash only */
+#define GTPC_TEID_V6_FLOW 0x18	/* hash only */
+
+/* Use for GTP-U and extended headers for the PSC (PDU Session Container).
+ * The format of these GTP packets includes TEID and QFI.
+ * In 5G communication using UPF (User Plane Function),
+ * data communication with this extended header is performed.
+ */
+#define GTPU_EH_V4_FLOW 0x19	/* hash only */
+#define GTPU_EH_V6_FLOW 0x1a	/* hash only */
+
+/* Use for GTP-U IPv4 and v6 PSC (PDU Session Container) extended headers.
+ * This differs from GTPU_EH_V(4|6)_FLOW in that it is distinguished by
+ * UL/DL included in the PSC.
+ * There are differences in the data included based on Downlink/Uplink,
+ * and can be used to distinguish packets.
+ * The functions described so far are useful when you want to
+ * handle communication from the mobile network in UPF, PGW, etc.
+ */
+#define GTPU_UL_V4_FLOW 0x1b	/* hash only */
+#define GTPU_UL_V6_FLOW 0x1c	/* hash only */
+#define GTPU_DL_V4_FLOW 0x1d	/* hash only */
+#define GTPU_DL_V6_FLOW 0x1e	/* hash only */
+
 /* Flag to enable additional fields in struct ethtool_rx_flow_spec */
 #define	FLOW_EXT	0x80000000
 #define	FLOW_MAC_EXT	0x40000000
@@ -2037,6 +2084,7 @@  static inline int ethtool_validate_duplex(__u8 duplex)
 #define	RXH_IP_DST	(1 << 5)
 #define	RXH_L4_B_0_1	(1 << 6) /* src port in case of TCP/UDP/SCTP */
 #define	RXH_L4_B_2_3	(1 << 7) /* dst port in case of TCP/UDP/SCTP */
+#define	RXH_GTP_TEID	(1 << 8) /* teid in case of GTP */
 #define	RXH_DISCARD	(1 << 31)
 
 #define	RX_CLS_FLOW_DISC	0xffffffffffffffffULL