BR Rongwei ________________________________ From: Thomas Monjalon Sent: Wednesday, June 5, 2024 17:35 To: rongwei liu Cc: Dariusz Sosnowski ; dev@dpdk.org ; Matan Azrad ; Slava Ovsiienko ; Ori Kam ; Suanming Mou ; Aman Singh ; Yuying Zhang ; Ferruh Yigit ; Andrew Rybchenko 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?