DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Minggang(Gavin) Li" <gavinl@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>,
	Matan Azrad <matan@nvidia.com>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	Ori Kam <orika@nvidia.com>,
	"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
	Aman Singh <aman.deep.singh@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Raslan Darawsheh <rasland@nvidia.com>
Subject: RE: [V2] app/testpmd: restore VXLAN-GPE support
Date: Tue, 23 Jul 2024 14:09:16 +0000	[thread overview]
Message-ID: <IA1PR12MB6019CBAE4ED6AB29DBC304D7B3A92@IA1PR12MB6019.namprd12.prod.outlook.com> (raw)
In-Reply-To: <1fb2b005-8b99-4550-aed2-f40f49b257a9@amd.com>

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Tuesday, July 23, 2024 4:06 PM
> To: Minggang(Gavin) Li <gavinl@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-
> Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Aman Singh
> <aman.deep.singh@intel.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [V2] app/testpmd: restore VXLAN-GPE support
> 
> On 7/23/2024 8:37 AM, Gavin Li wrote:
> > VXLAN-GPE support was removed from testpmd recently. Drivers which are
> > not migrated are still using VXLAN-GPE in tests.
> >
> > This commit is to restore the support for VXLAN-GPE in testpmd.
> >
> > After this change, there are two command line items with the same name, ie.
> > "protocol". One is for the new VXLAN extensions and the other is for
> > the deprecated VXLAN-GPE. Add a new one that is more obvious for the
> > new VXLAN structure since the two have different command line context.
> >
> > Fixes: da118115d95c ("app/testpmd: support matching any VXLAN field")
> > Signed-off-by: Gavin Li <gavinl@nvidia.com>
> > ---
> >  app/test-pmd/cmdline_flow.c                 | 71 ++++++++++++++++++++-
> >  doc/guides/testpmd_app_ug/testpmd_funcs.rst | 21 ++++--
> >  2 files changed, 83 insertions(+), 9 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index a76b44bf39..2c5a0491d2 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -391,7 +391,7 @@ enum index {
> >  	ITEM_VXLAN_FLAG_D,
> >  	ITEM_VXLAN_FLAG_A,
> >  	ITEM_VXLAN_GBP_ID,
> > -	ITEM_VXLAN_GPE_PROTO,
> > +	ITEM_VXLAN_GPE_PROTOCOL,
> >
> 
> With more obvious naming I was suggesting something like:
> ITEM_VXLAN_GPE_PROTO_IN_COMBINED_STRUCT
> 
> Or we can go the other way around, give obvious name to the other one, and
> when it is removed, this saves us some work to rename. Whichever you thik
> better is good.
ACK. I prefer the second one. 
Eg. ITEM_VXLAN_GPE_PROTO_IN_DEPRECATED_VXLAN_GPE_HDR.
What do you think---I'm not good at naming?
> 
> 
> Also can you please add code comment, I think at least giving struct names can be
> useful, something like:
> /* Used for "struct rte_vxlan_gpe_hdr", deprecated, prefer ... */
> 
> Similar comment to the both can help.
ACK
> 
> 
> >  	ITEM_VXLAN_FIRST_RSVD,
> >  	ITEM_VXLAN_SECND_RSVD,
> >  	ITEM_VXLAN_THIRD_RSVD,
> > @@ -423,6 +423,12 @@ enum index {
> >  	ITEM_GENEVE_VNI,
> >  	ITEM_GENEVE_PROTO,
> >  	ITEM_GENEVE_OPTLEN,
> > +	ITEM_VXLAN_GPE,
> > +	ITEM_VXLAN_GPE_VNI,
> > +	ITEM_VXLAN_GPE_PROTO,
> > +	ITEM_VXLAN_GPE_FLAGS,
> > +	ITEM_VXLAN_GPE_RSVD0,
> > +	ITEM_VXLAN_GPE_RSVD1,
> >  	ITEM_ARP_ETH_IPV4,
> >  	ITEM_ARP_ETH_IPV4_SHA,
> >  	ITEM_ARP_ETH_IPV4_SPA,
> > @@ -1612,6 +1618,7 @@ static const enum index next_item[] = {
> >  	ITEM_GTPC,
> >  	ITEM_GTPU,
> >  	ITEM_GENEVE,
> > +	ITEM_VXLAN_GPE,
> >  	ITEM_ARP_ETH_IPV4,
> >  	ITEM_IPV6_EXT,
> >  	ITEM_IPV6_FRAG_EXT,
> > @@ -1794,7 +1801,7 @@ static const enum index item_vxlan[] = {
> >  	ITEM_VXLAN_FLAG_D,
> >  	ITEM_VXLAN_FLAG_A,
> >  	ITEM_VXLAN_GBP_ID,
> > -	ITEM_VXLAN_GPE_PROTO,
> > +	ITEM_VXLAN_GPE_PROTOCOL,
> >  	ITEM_VXLAN_FIRST_RSVD,
> >  	ITEM_VXLAN_SECND_RSVD,
> >  	ITEM_VXLAN_THIRD_RSVD,
> > @@ -1864,6 +1871,16 @@ static const enum index item_geneve[] = {
> >  	ZERO,
> >  };
> >
> > +static const enum index item_vxlan_gpe[] = {
> > +	ITEM_VXLAN_GPE_VNI,
> > +	ITEM_VXLAN_GPE_PROTO,
> > +	ITEM_VXLAN_GPE_FLAGS,
> > +	ITEM_VXLAN_GPE_RSVD0,
> > +	ITEM_VXLAN_GPE_RSVD1,
> > +	ITEM_NEXT,
> > +	ZERO,
> > +};
> > +
> >  static const enum index item_arp_eth_ipv4[] = {
> >  	ITEM_ARP_ETH_IPV4_SHA,
> >  	ITEM_ARP_ETH_IPV4_SPA,
> > @@ -4992,7 +5009,7 @@ static const struct token token_list[] = {
> >  		.args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_vxlan,
> >  					     hdr.policy_id)),
> >  	},
> > -	[ITEM_VXLAN_GPE_PROTO] = {
> > +	[ITEM_VXLAN_GPE_PROTOCOL] = {
> >  		.name = "protocol",
> >  		.help = "VXLAN GPE next protocol",
> >  		.next = NEXT(item_vxlan, NEXT_ENTRY(COMMON_UNSIGNED),
> @@ -5241,6
> > +5258,54 @@ static const struct token token_list[] = {
> >  						  ver_opt_len_o_c_rsvd0,
> >  						  "\x3f\x00")),
> >  	},
> > +	[ITEM_VXLAN_GPE] = {
> > +		.name = "vxlan-gpe",
> > +		.help = "match VXLAN-GPE header",
> > +		.priv = PRIV_ITEM(VXLAN_GPE,
> > +				  sizeof(struct rte_flow_item_vxlan_gpe)),
> > +		.next = NEXT(item_vxlan_gpe),
> > +		.call = parse_vc,
> > +	},
> > +	[ITEM_VXLAN_GPE_VNI] = {
> > +		.name = "vni",
> > +		.help = "VXLAN-GPE identifier",
> > +		.next = NEXT(item_vxlan_gpe,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > +			     item_param),
> > +		.args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_vxlan_gpe,
> > +					     hdr.vni)),
> > +	},
> > +	[ITEM_VXLAN_GPE_PROTO] = {
> > +		.name = "protocol",
> > +		.help = "VXLAN-GPE next protocol",
> > +		.next = NEXT(item_vxlan_gpe,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > +			     item_param),
> > +		.args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_vxlan_gpe,
> > +					     protocol)),
> > +	},
> > +	[ITEM_VXLAN_GPE_FLAGS] = {
> > +		.name = "flags",
> > +		.help = "VXLAN-GPE flags",
> > +		.next = NEXT(item_vxlan_gpe,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > +			     item_param),
> > +		.args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_vxlan_gpe,
> > +					     flags)),
> > +	},
> > +	[ITEM_VXLAN_GPE_RSVD0] = {
> > +		.name = "rsvd0",
> > +		.help = "VXLAN-GPE rsvd0",
> > +		.next = NEXT(item_vxlan_gpe,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > +			     item_param),
> > +		.args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_vxlan_gpe,
> > +					     rsvd0)),
> > +	},
> > +	[ITEM_VXLAN_GPE_RSVD1] = {
> > +		.name = "rsvd1",
> > +		.help = "VXLAN-GPE rsvd1",
> > +		.next = NEXT(item_vxlan_gpe,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > +			     item_param),
> > +		.args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_vxlan_gpe,
> > +					     rsvd1)),
> > +	},
> >  	[ITEM_ARP_ETH_IPV4] = {
> >  		.name = "arp_eth_ipv4",
> >  		.help = "match ARP header for Ethernet/IPv4", diff --git
> > a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > index c19b4f8958..f00ab07605 100644
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > @@ -214,6 +214,7 @@ For example:
> >       vxlan
> >       geneve
> >       nvgre
> > +     vxlan-gpe
> >
> >  show port (module_eeprom|eeprom)
> >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > @@ -1103,12 +1104,12 @@ Where:
> >  * ``ip|udp|tcp|sctp`` always relate to  the inner layer.
> >
> >  * ``outer-ip`` relates to the outer IP layer (only for IPv4) in the
> > case where the packet is recognized
> > -  as a tunnel packet by the forwarding engine (geneve, gre, gtp, ipip and vxlan
> are supported).
> > -  See also the ``csum parse-tunnel`` command.
> > +  as a tunnel packet by the forwarding engine (geneve, gre, gtp,
> > + ipip, vxlan and vxlan-gpe are  supported). See also the ``csum parse-tunnel``
> command.
> >
> >  * ``outer-udp`` relates to the outer UDP layer in the case where the
> > packet is recognized
> > -  as a tunnel packet by the forwarding engine (geneve, gtp and vxlan are
> supported).
> > -  See also the ``csum parse-tunnel`` command.
> > +  as a tunnel packet by the forwarding engine (geneve, gtp, vxlan and
> > + vxlan-gpe are  supported). See also the ``csum parse-tunnel`` command.
> >
> >  .. note::
> >
> > @@ -1123,7 +1124,7 @@ engine::
> >     testpmd> csum parse-tunnel (on|off) (tx_port_id)
> >
> >  If enabled, the csum forward engine will try to recognize supported
> > -tunnel headers (geneve, gtp, gre, ipip, vxlan).
> > +tunnel headers (geneve, gtp, gre, ipip, vxlan, vxlan-gpe).
> >
> >  If disabled, treat tunnel packets as non-tunneled packets (a inner
> > header is handled as a packet payload).
> > @@ -2221,7 +2222,7 @@ port config udp_tunnel_port
> >
> >  Add/remove UDP tunnel port for VXLAN/GENEVE tunneling protocols::
> >
> > -    testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve|ecpri
> (udp_port)
> > +    testpmd> port config (port_id) udp_tunnel_port add|rm
> > + vxlan|geneve|vxlan-gpe|ecpri (udp_port)
> >
> >  port config tx_metadata
> >  ~~~~~~~~~~~~~~~~~~~~~~~
> > @@ -3745,6 +3746,14 @@ This section lists supported pattern items and their
> attributes, if any.
> >    - ``data {hex string}``: GENEVE option data, the length is defined by
> >      ``length`` field.
> >
> > +- ``vxlan-gpe``: match VXLAN-GPE header.
> > +
> > +  - ``vni {unsigned}``: VXLAN-GPE identifier.
> > +  - ``flags {unsigned}``: VXLAN-GPE flags.
> > +  - ``protocol {unsigned}`` : VXLAN-GPE next protocol.
> > +  - ``rsvd0 {unsigned}``: VXLAN-GPE reserved field 0.
> > +  - ``rsvd1 {unsigned}``: VXLAN-GPE reserved field 1.
> > +
> >  - ``arp_eth_ipv4``: match ARP header for Ethernet/IPv4.
> >
> >    - ``sha {MAC-48}``: sender hardware address.


  reply	other threads:[~2024-07-23 14:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-17  7:11 [V1] " Gavin Li
2024-07-19 20:24 ` Ferruh Yigit
2024-07-22  7:10   ` Minggang(Gavin) Li
2024-07-22  9:36     ` Ferruh Yigit
2024-07-22 13:04       ` Thomas Monjalon
2024-07-22 13:41         ` Ferruh Yigit
2024-07-22 14:43 ` Ferruh Yigit
2024-07-23  6:29   ` Minggang(Gavin) Li
2024-07-23  7:37 ` [V2] " Gavin Li
2024-07-23  8:05   ` Ferruh Yigit
2024-07-23 14:09     ` Minggang(Gavin) Li [this message]
2024-07-23 14:26   ` [V3] " Gavin Li
2024-07-23 16:13     ` Ferruh Yigit
2024-07-23 16:48     ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=IA1PR12MB6019CBAE4ED6AB29DBC304D7B3A92@IA1PR12MB6019.namprd12.prod.outlook.com \
    --to=gavinl@nvidia.com \
    --cc=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=rasland@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).