> -----Original Message----- > From: Andrew Rybchenko <arybche...@solarflare.com> > Sent: Wednesday, August 5, 2020 4:44 PM > To: Dekel Peled <dek...@mellanox.com>; dev@dpdk.org > Cc: jerinjac...@gmail.com; step...@networkplumber.org; > ajit.khapa...@broadcom.com; maxime.coque...@redhat.com; > olivier.m...@6wind.com; david.march...@redhat.com; > ferruh.yi...@intel.com; Asaf Penso <as...@mellanox.com> > Subject: Re: [dpdk-dev] [PATCH] doc: announce change in ETH item struct > > On 8/5/20 4:31 PM, Dekel Peled wrote: > > Thanks, PSB. > > > >> -----Original Message----- > >> From: Andrew Rybchenko <arybche...@solarflare.com> > >> Sent: Wednesday, August 5, 2020 1:49 PM > >> To: Dekel Peled <dek...@mellanox.com>; dev@dpdk.org > >> Cc: jerinjac...@gmail.com; step...@networkplumber.org; > >> ajit.khapa...@broadcom.com; maxime.coque...@redhat.com; > >> olivier.m...@6wind.com; david.march...@redhat.com; > >> ferruh.yi...@intel.com; Asaf Penso <as...@mellanox.com> > >> Subject: Re: [dpdk-dev] [PATCH] doc: announce change in ETH item > >> struct > >> > >> On 8/4/20 7:01 PM, Dekel Peled wrote: > >>> Struct rte_flow_item_eth will be modified to include additional > >>> values, indicating existence or absence of VLAN headers following > >>> the ETH header, as proposed in RFC > >>> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails. > >> dpdk.org%2Farchives%2Fdev%2F2020- > >> > August%2F177349.html&data=02%7C01%7Cdekelp%40mellanox.com%7 > >> > C7d12c0524d434c10f35a08d8392d3f53%7Ca652971c7d2e4d9ba6a4d149256f46 > >> > 1b%7C0%7C0%7C637322213783925660&sdata=4rEXCifnCHd2%2FA6AU4 > >> F3vjBcD7CfoTpT0traJ2z1fBk%3D&reserved=0. > >>> Because of ABI break this change is proposed for 20.11. > >>> > >>> Signed-off-by: Dekel Peled <dek...@mellanox.com> > >>> --- > >>> doc/guides/rel_notes/deprecation.rst | 5 +++++ > >>> 1 file changed, 5 insertions(+) > >>> > >>> diff --git a/doc/guides/rel_notes/deprecation.rst > >>> b/doc/guides/rel_notes/deprecation.rst > >>> index 5201142..6241709 100644 > >>> --- a/doc/guides/rel_notes/deprecation.rst > >>> +++ b/doc/guides/rel_notes/deprecation.rst > >>> @@ -115,6 +115,11 @@ Deprecation Notices > >>> following the IPv6 header, as proposed in RFC > >>> > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails. > >> dpdk.org%2Farchives%2Fdev%2F2020- > >> > August%2F177257.html&data=02%7C01%7Cdekelp%40mellanox.com%7 > >> > C7d12c0524d434c10f35a08d8392d3f53%7Ca652971c7d2e4d9ba6a4d149256f46 > >> > 1b%7C0%7C0%7C637322213783925660&sdata=Ix4Y2vEXMoBek%2BkXw > >> QazY11a9mkc3aiZRJDX9cbUiZk%3D&reserved=0. > >>> > >>> +* ethdev: The ``struct rte_flow_item_eth`` struct will be modified > >>> +to include > >>> + additional values, indicating existence or absence of VLAN > >>> +headers > >>> + following the ETH header, as proposed in RFC > >>> + > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails. > >> dpdk.org%2Farchives%2Fdev%2F2020- > >> > August%2F177349.html&data=02%7C01%7Cdekelp%40mellanox.com%7 > >> > C7d12c0524d434c10f35a08d8392d3f53%7Ca652971c7d2e4d9ba6a4d149256f46 > >> > 1b%7C0%7C0%7C637322213783925660&sdata=4rEXCifnCHd2%2FA6AU4 > >> F3vjBcD7CfoTpT0traJ2z1fBk%3D&reserved=0. > >> > >> It is unclear how it will coexist with VLAN items in a pattern. > > Same as the existing proto field coexist with following VLAN items. > > > >> Are you going to add consistency checks on ethdev-layer? > > Not planned currently. > > IMHO, it is a must requirement if you introduce interface which has inter- > dependencies and requires generic consistency check. > It must be a part of ethdev, not every PMD. OK, will take it into account in the implementation.
> > > > >> > >> Also it is unclear why both bit fields and a number are required. > > I agree it is redundancy, added for flexibility, but can leave num_of_vlans > only. > > > >> > >> Referenced RFC lacks definition of S-VLAN anc C-VLAN in the context. > >> Exact definition to avoid ambiguity. > > These are well defined terms, I will add reference to spec. > > Basically, I agree that changes in the ETH item may be required and OK to > acknowledge the deprecation notice without deep technical details. The only > requirement is API backward compatibility (i.e. just recompiled code to take > ABI changes into account must work). Of course, code including proposed change is built and runs. > > > > >> > >> So, it looks required to modify the structure, but I'd not stick to > >> referenced RFC, since the result could differ a lot. May be reference > >> it as just an example. > > Thank you. > > > >
