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.
next prev parent 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).