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