[PATCH v4 2/3] ethdev: add VXLAN last reserved field

[rongwei liu]

BR

Rongwei



________________________________
From: Thomas Monjalon <thomas at monjalon.net>
Sent: Wednesday, June 5, 2024 17:35
To: rongwei liu <rongweil at nvidia.com>
Cc: Dariusz Sosnowski <dsosnowski at nvidia.com>; dev at dpdk.org <dev at dpdk.org>; Matan Azrad <matan at nvidia.com>; Slava Ovsiienko <viacheslavo at nvidia.com>; Ori Kam <orika at nvidia.com>; Suanming Mou <suanmingm at nvidia.com>; Aman Singh <aman.deep.singh at intel.com>; Yuying Zhang <yuying.zhang at intel.com>; Ferruh Yigit <ferruh.yigit at amd.com>; Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
Subject: Re: [PATCH v4 2/3] ethdev: add VXLAN last reserved field

External email: Use caution opening links or attachments


05/06/2024 10:14, rongwei liu:
> > > > > In this patch, "vxlan_last_rsvd" is used in testpmd, so it matches
> > > > > existing "last_rsvd" field in VXLAN item. If we choose to use
> > > > > "rsvd1",
> > > > > we should probably rename all other instances of "last_rsvd" to
> > > > > match.> >
> > > >
> > > > I prefer "vxlan_last_rsvd" for 2 reasons:
> > > >         - it is more meaningful
> > > >         - we are adding first, second and third reserved fields to
> > > >         match
> > > >         the 3 bytes of rsvd0 (patch to come)
> > >
> > > Sound clear and reasonable. I would like to propose the alignment between rte_flow_field_id and rte_vxlan_hdr:
> > >   1.
> > >
> > > RTE_FLOW_FIELD_VXLAN_RSVD1  ---> RTE_FLOW_FIELD_VXLAN_LAST_RSVD
> > >
> > >   2.
> > >
> > > "uint8_t rsvd1"  ---->  "uint8_t last_rsvd"
> >
> > We don't change rte_vxlan_hdr, because we avoid breaking compatibility.
>
> How about to add a new union:
>
> union {
>     uint8_t rsvd1;
>     uint8_t last_rsvd;
> }
>  RTE_FLOW_FIELD_VXLAN_LAST_RSVD will perfectly match the rte_vxlan_hdr definition.

It could be a solution, yes,
but I don't see it in your v5.

Should I add this change in my serial or expect it in the upcoming new VXLAN header definitions?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20240605/de13608f/attachment-0001.htm>