mbox series

[V1,0/5] support VXLAN-GPE header fields(flags, rsvd0 and rsvd1) matching

Message ID 20240112080210.1288356-1-gavinl@nvidia.com (mailing list archive)
Headers
Series support VXLAN-GPE header fields(flags, rsvd0 and rsvd1) matching |

Message

Gavin Li Jan. 12, 2024, 8:02 a.m. UTC 
  Previously, VXLAN-GPE in DPDK only supports VNI and next protocol header
fields. This patch series add support for flags and reserved field 0 and
1.

Below is the VXLAN-GPE header defined in the lasted draft.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|R|Ver|I|P|B|O|       Reserved                |Next Protocol  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                VXLAN Network Identifier (VNI) |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gavin Li (5):
  net/mlx5: support VXLAN-GPE flags matching
  app/testpmd: support VXLAN-GPE flags
  net/mlx5: support VXLAN-GPE reserved fields matching
  app/testpmd: support VXLAN-GPE reserved fields
  net/mlx5/hws: support VXLAN-GPE matching

 app/test-pmd/cmdline_flow.c                 |  30 +++++
 doc/guides/nics/mlx5.rst                    |   5 +
 doc/guides/rel_notes/release_24_03.rst      |   6 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   3 +
 drivers/net/mlx5/hws/mlx5dr_definer.c       | 117 ++++++++++++++++++++
 drivers/net/mlx5/hws/mlx5dr_definer.h       |  13 +++
 drivers/net/mlx5/mlx5_flow.c                |   6 +
 drivers/net/mlx5/mlx5_flow_dv.c             |  32 +++++-
 drivers/net/mlx5/mlx5_flow_hw.c             |   1 +
 9 files changed, 207 insertions(+), 6 deletions(-)

Comments

Raslan Darawsheh Jan. 24, 2024, 9:46 a.m. UTC | #1 
Hi,

> -----Original Message-----
> From: Gavin Li <gavinl@nvidia.com>
> Sent: Friday, January 12, 2024 10:02 AM
> To: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>; Ori Kam <orika@nvidia.com>;
> aman.deep.singh@intel.com; yuying.zhang@intel.com; Dariusz Sosnowski
> <dsosnowski@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>;
> Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
> <matan@nvidia.com>
> Cc: Jiawei(Jonny) Wang <jiaweiw@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: [V1 0/5] support VXLAN-GPE header fields(flags, rsvd0 and rsvd1)
> matching
> 
> Previously, VXLAN-GPE in DPDK only supports VNI and next protocol header
> fields. This patch series add support for flags and reserved field 0 and 1.
> 
> Below is the VXLAN-GPE header defined in the lasted draft.
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |R|R|Ver|I|P|B|O|       Reserved                |Next Protocol  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                VXLAN Network Identifier (VNI) |   Reserved    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Gavin Li (5):
>   net/mlx5: support VXLAN-GPE flags matching
>   app/testpmd: support VXLAN-GPE flags
>   net/mlx5: support VXLAN-GPE reserved fields matching
>   app/testpmd: support VXLAN-GPE reserved fields
>   net/mlx5/hws: support VXLAN-GPE matching
> 
>  app/test-pmd/cmdline_flow.c                 |  30 +++++
>  doc/guides/nics/mlx5.rst                    |   5 +
>  doc/guides/rel_notes/release_24_03.rst      |   6 +
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |   3 +
>  drivers/net/mlx5/hws/mlx5dr_definer.c       | 117 ++++++++++++++++++++
>  drivers/net/mlx5/hws/mlx5dr_definer.h       |  13 +++
>  drivers/net/mlx5/mlx5_flow.c                |   6 +
>  drivers/net/mlx5/mlx5_flow_dv.c             |  32 +++++-
>  drivers/net/mlx5/mlx5_flow_hw.c             |   1 +
>  9 files changed, 207 insertions(+), 6 deletions(-)
> 
> --
> 2.39.1

Series applied to next-net-mlx,

Kindest regards
Raslan Darawsheh
Stephen Hemminger Feb. 19, 2024, 7:50 p.m. UTC | #2 
On Fri, 12 Jan 2024 10:02:05 +0200
Gavin Li <gavinl@nvidia.com> wrote:

> Previously, VXLAN-GPE in DPDK only supports VNI and next protocol header
> fields. This patch series add support for flags and reserved field 0 and
> 1.
> 
> Below is the VXLAN-GPE header defined in the lasted draft.
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |R|R|Ver|I|P|B|O|       Reserved                |Next Protocol  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                VXLAN Network Identifier (VNI) |   Reserved    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Would recommend against implementing anything in a draft RFC.
Things can change.  Learned the hard way when doing VXLAN driver for Linux.
The hardcoded port value in the Linux VXLAN driver is wrong because it matched
the draft RFC (got changed in final version). Because of strict compatibility
requirements the Linux driver could not be changed to the correct value.
Thomas Monjalon Feb. 19, 2024, 10:48 p.m. UTC | #3 
19/02/2024 20:50, Stephen Hemminger:
> On Fri, 12 Jan 2024 10:02:05 +0200
> Gavin Li <gavinl@nvidia.com> wrote:
> 
> > Previously, VXLAN-GPE in DPDK only supports VNI and next protocol header
> > fields. This patch series add support for flags and reserved field 0 and
> > 1.
> > 
> > Below is the VXLAN-GPE header defined in the lasted draft.
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |R|R|Ver|I|P|B|O|       Reserved                |Next Protocol  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                VXLAN Network Identifier (VNI) |   Reserved    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Would recommend against implementing anything in a draft RFC.
> Things can change.  Learned the hard way when doing VXLAN driver for Linux.
> The hardcoded port value in the Linux VXLAN driver is wrong because it matched
> the draft RFC (got changed in final version). Because of strict compatibility
> requirements the Linux driver could not be changed to the correct value.

The problem is that standardization may be slow.
Would it be acceptable without any compatibility guarantee?
Stephen Hemminger Feb. 19, 2024, 11:44 p.m. UTC | #4 
On Mon, 19 Feb 2024 23:48:31 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 19/02/2024 20:50, Stephen Hemminger:
> > On Fri, 12 Jan 2024 10:02:05 +0200
> > Gavin Li <gavinl@nvidia.com> wrote:
> >   
> > > Previously, VXLAN-GPE in DPDK only supports VNI and next protocol header
> > > fields. This patch series add support for flags and reserved field 0 and
> > > 1.
> > > 
> > > Below is the VXLAN-GPE header defined in the lasted draft.
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |R|R|Ver|I|P|B|O|       Reserved                |Next Protocol  |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                VXLAN Network Identifier (VNI) |   Reserved    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
> > 
> > Would recommend against implementing anything in a draft RFC.
> > Things can change.  Learned the hard way when doing VXLAN driver for Linux.
> > The hardcoded port value in the Linux VXLAN driver is wrong because it matched
> > the draft RFC (got changed in final version). Because of strict compatibility
> > requirements the Linux driver could not be changed to the correct value.  
> 
> The problem is that standardization may be slow.
> Would it be acceptable without any compatibility guarantee?

Never mark it stable until RFC is done.