[v10] ethdev: add HIGIG2 key field to flow API
Checks
Commit Message
From: Kiran Kumar K <kirankumark@marvell.com>
Add new rte_flow_item_higig2_hdr in order to match higig2 header.
It is a layer 2.5 protocol and used in Broadcom switches.
Header format is based on the following document.
http://read.pudn.com/downloads558/doc/comm/2301468/HiGig_protocol.pdf
Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
---
V10 Changes:
* Avoid structure padding
V9 Changes:
* Fix gcc 4.8 compile issue
V8 Changes:
* Fixed gcc 4.8 compile issue
V7 changes:
* Added doxygen comments
* Moved rte_flow specific code to rte_flow.h
V6 changes:
* Updated doxy-api
V5 changes:
* Changed broadcom to Broadcom
* Changed RTE_HIGIG2_H to RTE_HIGIG_H
* Fixed meson build
V4 Changes:
* Removed packed attribute
V3 Changes:
* Fixed Copyright header
* Fixed version info in the subject
V2 Changes:
* Added support in testpmd to parse the higig2 item
* Moved the higig2 header to new file
* Added indentation in doc
app/test-pmd/cmdline_flow.c | 33 +++++++
doc/api/doxy-api-index.md | 3 +-
doc/guides/prog_guide/rte_flow.rst | 8 ++
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 29 ++++++
lib/librte_net/Makefile | 2 +-
lib/librte_net/meson.build | 3 +-
lib/librte_net/rte_higig.h | 145 +++++++++++++++++++++++++++++
8 files changed, 221 insertions(+), 3 deletions(-)
create mode 100644 lib/librte_net/rte_higig.h
--
2.17.1
Comments
On 10/22/2019 5:16 AM, kirankumark@marvell.com wrote:
> From: Kiran Kumar K <kirankumark@marvell.com>
>
> Add new rte_flow_item_higig2_hdr in order to match higig2 header.
> It is a layer 2.5 protocol and used in Broadcom switches.
> Header format is based on the following document.
> http://read.pudn.com/downloads558/doc/comm/2301468/HiGig_protocol.pdf
>
> Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
Applied to dpdk-next-net/master, thanks.
Hi,
This patch broke the compilation of MLX5 PMD in debug mode:
from /root/dpdk/x86_64-native-linux-gcc/include/rte_ethdev_driver.h:18,
from /root/dpdk/drivers/net/mlx5/mlx5_mp.c:11:
/root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:112:2: error: type of bit-field 'opcode' is a GCC extension [-Werror=pedantic]
uint16_t opcode:3;
^
/root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:113:2: error: type of bit-field 'resv1' is a GCC extension [-Werror=pedantic]
uint16_t resv1:2;
^
/root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:114:2: error: type of bit-field 'src_t' is a GCC extension [-Werror=pedantic]
uint16_t src_t:1;
^
/root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:115:2: error: type of bit-field 'pfm' is a GCC extension [-Werror=pedantic]
uint16_t pfm:2;
^
/root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:116:2: error: type of bit-field 'resv2' is a GCC extension [-Werror=pedantic]
uint16_t resv2:5;
^
/root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:117:2: error: type of bit-field 'hdr_ext_len' is a GCC extension [-Werror=pedantic]
uint16_t hdr_ext_len:3;
and this is with gcc 4.8.5
Kindest regards,
Raslan Darawsheh
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ferruh Yigit
> Sent: Tuesday, October 22, 2019 12:20 PM
> To: kirankumark@marvell.com; Adrien Mazarguil
> <adrien.mazarguil@6wind.com>; Wenzhuo Lu <wenzhuo.lu@intel.com>;
> Jingjing Wu <jingjing.wu@intel.com>; Bernard Iremonger
> <bernard.iremonger@intel.com>; John McNamara
> <john.mcnamara@intel.com>; Marko Kovacevic
> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>;
> Andrew Rybchenko <arybchenko@solarflare.com>; Olivier Matz
> <olivier.matz@6wind.com>
> Cc: dev@dpdk.org; ajit.khaparde@broadcom.com
> Subject: Re: [dpdk-dev] [PATCH v10] ethdev: add HIGIG2 key field to flow
> API
>
> On 10/22/2019 5:16 AM, kirankumark@marvell.com wrote:
> > From: Kiran Kumar K <kirankumark@marvell.com>
> >
> > Add new rte_flow_item_higig2_hdr in order to match higig2 header.
> > It is a layer 2.5 protocol and used in Broadcom switches.
> > Header format is based on the following document.
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fread.p
> udn.com%2Fdownloads558%2Fdoc%2Fcomm%2F2301468%2FHiGig_protocol
> .pdf&data=02%7C01%7Crasland%40mellanox.com%7C316c5935a21b41ff
> 8e5708d756d10626%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C6
> 37073328075459541&sdata=3sL1lSFraI2KMD6UAJj%2FP2cFwloEflX1vNCY
> lv%2B4fG4%3D&reserved=0
> >
> > Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
> > Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> > Acked-by: Olivier Matz <olivier.matz@6wind.com>
>
> Applied to dpdk-next-net/master, thanks.
Hi,
On Wed, Oct 23, 2019 at 10:50:52AM +0000, Raslan Darawsheh wrote:
> Hi,
>
> This patch broke the compilation of MLX5 PMD in debug mode:
>
> from /root/dpdk/x86_64-native-linux-gcc/include/rte_ethdev_driver.h:18,
> from /root/dpdk/drivers/net/mlx5/mlx5_mp.c:11:
> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:112:2: error: type of bit-field 'opcode' is a GCC extension [-Werror=pedantic]
> uint16_t opcode:3;
> ^
> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:113:2: error: type of bit-field 'resv1' is a GCC extension [-Werror=pedantic]
> uint16_t resv1:2;
> ^
> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:114:2: error: type of bit-field 'src_t' is a GCC extension [-Werror=pedantic]
> uint16_t src_t:1;
> ^
> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:115:2: error: type of bit-field 'pfm' is a GCC extension [-Werror=pedantic]
> uint16_t pfm:2;
> ^
> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:116:2: error: type of bit-field 'resv2' is a GCC extension [-Werror=pedantic]
> uint16_t resv2:5;
> ^
> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:117:2: error: type of bit-field 'hdr_ext_len' is a GCC extension [-Werror=pedantic]
> uint16_t hdr_ext_len:3;
>
> and this is with gcc 4.8.5
From https://stackoverflow.com/questions/10906238/warning-when-using-bitfield-with-unsigned-char
it seems that it is allowed in c99, so I guess it's a gcc 4.8 bug.
Adding __extension__ above the struct solves the warnings, I suggest to
add it.
Olivier
> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Wednesday, October 23, 2019 5:09 PM
> To: Raslan Darawsheh <rasland@mellanox.com>
> Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>; Adrien Mazarguil
> <adrien.mazarguil@6wind.com>; Wenzhuo Lu <wenzhuo.lu@intel.com>;
> Jingjing Wu <jingjing.wu@intel.com>; Bernard Iremonger
> <bernard.iremonger@intel.com>; John McNamara
> <john.mcnamara@intel.com>; Marko Kovacevic <marko.kovacevic@intel.com>;
> Thomas Monjalon <thomas@monjalon.net>; Andrew Rybchenko
> <arybchenko@solarflare.com>; dev@dpdk.org; ajit.khaparde@broadcom.com
> Subject: [EXT] Re: [dpdk-dev] [PATCH v10] ethdev: add HIGIG2 key field to flow
> API
>
> External Email
>
> ----------------------------------------------------------------------
> Hi,
>
>
>
> On Wed, Oct 23, 2019 at 10:50:52AM +0000, Raslan Darawsheh wrote:
>
> > Hi,
>
> >
>
> > This patch broke the compilation of MLX5 PMD in debug mode:
>
> >
>
> > from /root/dpdk/x86_64-native-linux-
> gcc/include/rte_ethdev_driver.h:18,
>
> > from /root/dpdk/drivers/net/mlx5/mlx5_mp.c:11:
>
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:112:2: error: type of
> bit-field 'opcode' is a GCC extension [-Werror=pedantic]
>
> > uint16_t opcode:3;
>
> > ^
>
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:113:2: error: type of
> bit-field 'resv1' is a GCC extension [-Werror=pedantic]
>
> > uint16_t resv1:2;
>
> > ^
>
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:114:2: error: type of
> bit-field 'src_t' is a GCC extension [-Werror=pedantic]
>
> > uint16_t src_t:1;
>
> > ^
>
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:115:2: error: type of
> bit-field 'pfm' is a GCC extension [-Werror=pedantic]
>
> > uint16_t pfm:2;
>
> > ^
>
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:116:2: error: type of
> bit-field 'resv2' is a GCC extension [-Werror=pedantic]
>
> > uint16_t resv2:5;
>
> > ^
>
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:117:2: error: type of
> bit-field 'hdr_ext_len' is a GCC extension [-Werror=pedantic]
>
> > uint16_t hdr_ext_len:3;
>
> >
>
> > and this is with gcc 4.8.5
>
>
>
> From https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__stackoverflow.com_questions_10906238_warning-2Dwhen-2Dusing-
> 2Dbitfield-2Dwith-2Dunsigned-
> 2Dchar&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil1Z6oBUR
> wkTThyuRbLAY9LdfiaT6HA&m=GZ-
> 6cngPycaUlGJT20VEOf9oTcp5PMwk7j1JV1vAQfs&s=SCg5yVPS4zZa8GSn9bl_eUtI
> vBmoDzi35PspWUttIUY&e=
>
> it seems that it is allowed in c99, so I guess it's a gcc 4.8 bug.
>
>
>
> Adding __extension__ above the struct solves the warnings, I suggest to
>
> add it.
/**
*
* higig2 ppt type1 header.
*/
RTE_STD_C11
struct rte_higig2_ppt_type1 {
uint16_t classification;
uint16_t resv;
uint16_t vid;
#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
uint16_t opcode:3;
uint16_t resv1:2;
uint16_t src_t:1;
uint16_t pfm:2;
uint16_t resv2:5;
uint16_t hdr_ext_len:3;
#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
uint16_t pfm:2;
uint16_t src_t:1;
uint16_t resv1:2;
uint16_t opcode:3;
uint16_t hdr_ext_len:3;
uint16_t resv2:5;
#endif
};
I have already added it. RTE_STD_C11 , this is a macro for __extension__.
/** C extension macro for environments lacking C11 features. */
#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
#define RTE_STD_C11 __extension__
#else
#define RTE_STD_C11
#endif
>
>
>
>
>
> Olivier
On Wed, Oct 23, 2019 at 11:43:58AM +0000, Kiran Kumar Kokkilagadda wrote:
> > -----Original Message-----
> > From: Olivier Matz <olivier.matz@6wind.com>
> > Sent: Wednesday, October 23, 2019 5:09 PM
> > To: Raslan Darawsheh <rasland@mellanox.com>
> > Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>; Adrien Mazarguil
> > <adrien.mazarguil@6wind.com>; Wenzhuo Lu <wenzhuo.lu@intel.com>;
> > Jingjing Wu <jingjing.wu@intel.com>; Bernard Iremonger
> > <bernard.iremonger@intel.com>; John McNamara
> > <john.mcnamara@intel.com>; Marko Kovacevic <marko.kovacevic@intel.com>;
> > Thomas Monjalon <thomas@monjalon.net>; Andrew Rybchenko
> > <arybchenko@solarflare.com>; dev@dpdk.org; ajit.khaparde@broadcom.com
> > Subject: [EXT] Re: [dpdk-dev] [PATCH v10] ethdev: add HIGIG2 key field to flow
> > API
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > Hi,
> >
> >
> >
> > On Wed, Oct 23, 2019 at 10:50:52AM +0000, Raslan Darawsheh wrote:
> >
> > > Hi,
> >
> > >
> >
> > > This patch broke the compilation of MLX5 PMD in debug mode:
> >
> > >
> >
> > > from /root/dpdk/x86_64-native-linux-
> > gcc/include/rte_ethdev_driver.h:18,
> >
> > > from /root/dpdk/drivers/net/mlx5/mlx5_mp.c:11:
> >
> > > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:112:2: error: type of
> > bit-field 'opcode' is a GCC extension [-Werror=pedantic]
> >
> > > uint16_t opcode:3;
> >
> > > ^
> >
> > > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:113:2: error: type of
> > bit-field 'resv1' is a GCC extension [-Werror=pedantic]
> >
> > > uint16_t resv1:2;
> >
> > > ^
> >
> > > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:114:2: error: type of
> > bit-field 'src_t' is a GCC extension [-Werror=pedantic]
> >
> > > uint16_t src_t:1;
> >
> > > ^
> >
> > > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:115:2: error: type of
> > bit-field 'pfm' is a GCC extension [-Werror=pedantic]
> >
> > > uint16_t pfm:2;
> >
> > > ^
> >
> > > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:116:2: error: type of
> > bit-field 'resv2' is a GCC extension [-Werror=pedantic]
> >
> > > uint16_t resv2:5;
> >
> > > ^
> >
> > > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:117:2: error: type of
> > bit-field 'hdr_ext_len' is a GCC extension [-Werror=pedantic]
> >
> > > uint16_t hdr_ext_len:3;
> >
> > >
> >
> > > and this is with gcc 4.8.5
> >
> >
> >
> > From https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__stackoverflow.com_questions_10906238_warning-2Dwhen-2Dusing-
> > 2Dbitfield-2Dwith-2Dunsigned-
> > 2Dchar&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil1Z6oBUR
> > wkTThyuRbLAY9LdfiaT6HA&m=GZ-
> > 6cngPycaUlGJT20VEOf9oTcp5PMwk7j1JV1vAQfs&s=SCg5yVPS4zZa8GSn9bl_eUtI
> > vBmoDzi35PspWUttIUY&e=
> >
> > it seems that it is allowed in c99, so I guess it's a gcc 4.8 bug.
> >
> >
> >
> > Adding __extension__ above the struct solves the warnings, I suggest to
> >
> > add it.
>
> /**
> *
> * higig2 ppt type1 header.
> */
> RTE_STD_C11
> struct rte_higig2_ppt_type1 {
> uint16_t classification;
> uint16_t resv;
> uint16_t vid;
> #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> uint16_t opcode:3;
> uint16_t resv1:2;
> uint16_t src_t:1;
> uint16_t pfm:2;
> uint16_t resv2:5;
> uint16_t hdr_ext_len:3;
> #elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> uint16_t pfm:2;
> uint16_t src_t:1;
> uint16_t resv1:2;
> uint16_t opcode:3;
> uint16_t hdr_ext_len:3;
> uint16_t resv2:5;
> #endif
> };
>
> I have already added it. RTE_STD_C11 , this is a macro for __extension__.
> /** C extension macro for environments lacking C11 features. */
> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
> #define RTE_STD_C11 __extension__
> #else
> #define RTE_STD_C11
> #endif
The __extension__ is only added if compiled for < c11.
But there is apparently a problem with gcc-4.8: even in c11, it does
not support bitfields on u16. See: https://godbolt.org/z/hRIbgg
On gcc-4.9, the problem disappeared: https://godbolt.org/z/kkzz9v
So as a workaround, using __extension__ should work, probably with a short
explanation.
On 10/23/2019 3:04 PM, Olivier Matz wrote:
> On Wed, Oct 23, 2019 at 11:43:58AM +0000, Kiran Kumar Kokkilagadda wrote:
>>> -----Original Message-----
>>> From: Olivier Matz <olivier.matz@6wind.com>
>>> Sent: Wednesday, October 23, 2019 5:09 PM
>>> To: Raslan Darawsheh <rasland@mellanox.com>
>>> Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Kiran Kumar Kokkilagadda
>>> <kirankumark@marvell.com>; Adrien Mazarguil
>>> <adrien.mazarguil@6wind.com>; Wenzhuo Lu <wenzhuo.lu@intel.com>;
>>> Jingjing Wu <jingjing.wu@intel.com>; Bernard Iremonger
>>> <bernard.iremonger@intel.com>; John McNamara
>>> <john.mcnamara@intel.com>; Marko Kovacevic <marko.kovacevic@intel.com>;
>>> Thomas Monjalon <thomas@monjalon.net>; Andrew Rybchenko
>>> <arybchenko@solarflare.com>; dev@dpdk.org; ajit.khaparde@broadcom.com
>>> Subject: [EXT] Re: [dpdk-dev] [PATCH v10] ethdev: add HIGIG2 key field to flow
>>> API
>>>
>>> External Email
>>>
>>> ----------------------------------------------------------------------
>>> Hi,
>>>
>>>
>>>
>>> On Wed, Oct 23, 2019 at 10:50:52AM +0000, Raslan Darawsheh wrote:
>>>
>>>> Hi,
>>>
>>>>
>>>
>>>> This patch broke the compilation of MLX5 PMD in debug mode:
>>>
>>>>
>>>
>>>> from /root/dpdk/x86_64-native-linux-
>>> gcc/include/rte_ethdev_driver.h:18,
>>>
>>>> from /root/dpdk/drivers/net/mlx5/mlx5_mp.c:11:
>>>
>>>> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:112:2: error: type of
>>> bit-field 'opcode' is a GCC extension [-Werror=pedantic]
>>>
>>>> uint16_t opcode:3;
>>>
>>>> ^
>>>
>>>> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:113:2: error: type of
>>> bit-field 'resv1' is a GCC extension [-Werror=pedantic]
>>>
>>>> uint16_t resv1:2;
>>>
>>>> ^
>>>
>>>> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:114:2: error: type of
>>> bit-field 'src_t' is a GCC extension [-Werror=pedantic]
>>>
>>>> uint16_t src_t:1;
>>>
>>>> ^
>>>
>>>> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:115:2: error: type of
>>> bit-field 'pfm' is a GCC extension [-Werror=pedantic]
>>>
>>>> uint16_t pfm:2;
>>>
>>>> ^
>>>
>>>> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:116:2: error: type of
>>> bit-field 'resv2' is a GCC extension [-Werror=pedantic]
>>>
>>>> uint16_t resv2:5;
>>>
>>>> ^
>>>
>>>> /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:117:2: error: type of
>>> bit-field 'hdr_ext_len' is a GCC extension [-Werror=pedantic]
>>>
>>>> uint16_t hdr_ext_len:3;
>>>
>>>>
>>>
>>>> and this is with gcc 4.8.5
>>>
>>>
>>>
>>> From https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__stackoverflow.com_questions_10906238_warning-2Dwhen-2Dusing-
>>> 2Dbitfield-2Dwith-2Dunsigned-
>>> 2Dchar&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil1Z6oBUR
>>> wkTThyuRbLAY9LdfiaT6HA&m=GZ-
>>> 6cngPycaUlGJT20VEOf9oTcp5PMwk7j1JV1vAQfs&s=SCg5yVPS4zZa8GSn9bl_eUtI
>>> vBmoDzi35PspWUttIUY&e=
>>>
>>> it seems that it is allowed in c99, so I guess it's a gcc 4.8 bug.
>>>
>>>
>>>
>>> Adding __extension__ above the struct solves the warnings, I suggest to
>>>
>>> add it.
>>
>> /**
>> *
>> * higig2 ppt type1 header.
>> */
>> RTE_STD_C11
>> struct rte_higig2_ppt_type1 {
>> uint16_t classification;
>> uint16_t resv;
>> uint16_t vid;
>> #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
>> uint16_t opcode:3;
>> uint16_t resv1:2;
>> uint16_t src_t:1;
>> uint16_t pfm:2;
>> uint16_t resv2:5;
>> uint16_t hdr_ext_len:3;
>> #elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
>> uint16_t pfm:2;
>> uint16_t src_t:1;
>> uint16_t resv1:2;
>> uint16_t opcode:3;
>> uint16_t hdr_ext_len:3;
>> uint16_t resv2:5;
>> #endif
>> };
>>
>> I have already added it. RTE_STD_C11 , this is a macro for __extension__.
>> /** C extension macro for environments lacking C11 features. */
>> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
>> #define RTE_STD_C11 __extension__
>> #else
>> #define RTE_STD_C11
>> #endif
>
> The __extension__ is only added if compiled for < c11.
> But there is apparently a problem with gcc-4.8: even in c11, it does
> not support bitfields on u16. See: https://godbolt.org/z/hRIbgg
>
> On gcc-4.9, the problem disappeared: https://godbolt.org/z/kkzz9v
>
> So as a workaround, using __extension__ should work, probably with a short
> explanation.
>
Thanks Olivier, this was also our finding with Raslan and he sent the fix already.
https://patches.dpdk.org/patch/61748/
Also it looks like gcc4.8 thinks this is not c11 standard but extension only for
uint16_t type, structs with uint32_t bit-fieds works as expected.
22/10/2019 06:16, kirankumark@marvell.com:
> --- a/doc/api/doxy-api-index.md
> +++ b/doc/api/doxy-api-index.md
> @@ -101,7 +101,8 @@ The public API headers are grouped by topics:
> [GSO] (@ref rte_gso.h),
> [frag/reass] (@ref rte_ip_frag.h),
> [LPM IPv4 route] (@ref rte_lpm.h),
> - [LPM IPv6 route] (@ref rte_lpm6.h)
> + [LPM IPv6 route] (@ref rte_lpm6.h),
> + [HIGIG] (@ref rte_higig.h)
Sorry, my comment is a bit late, but I would prefer to see HIGIG earlier in this list.
You say it is a protocol at layer 2.5, so it should be listed probably close to ICMP.
What is your opinion?
@@ -203,6 +203,9 @@ enum index {
ITEM_PPPOED,
ITEM_PPPOE_SEID,
ITEM_PPPOE_PROTO_ID,
+ ITEM_HIGIG2,
+ ITEM_HIGIG2_CLASSIFICATION,
+ ITEM_HIGIG2_VID,
/* Validate/create actions. */
ACTIONS,
@@ -675,6 +678,7 @@ static const enum index next_item[] = {
ITEM_PPPOES,
ITEM_PPPOED,
ITEM_PPPOE_PROTO_ID,
+ ITEM_HIGIG2,
END_SET,
ZERO,
};
@@ -939,6 +943,13 @@ static const enum index item_pppoe_proto_id[] = {
ZERO,
};
+static const enum index item_higig2[] = {
+ ITEM_HIGIG2_CLASSIFICATION,
+ ITEM_HIGIG2_VID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -2419,6 +2430,28 @@ static const struct token token_list[] = {
.next = NEXT(item_pppoe_proto_id),
.call = parse_vc,
},
+ [ITEM_HIGIG2] = {
+ .name = "higig2",
+ .help = "matches higig2 header",
+ .priv = PRIV_ITEM(HIGIG2,
+ sizeof(struct rte_flow_item_higig2_hdr)),
+ .next = NEXT(item_higig2),
+ .call = parse_vc,
+ },
+ [ITEM_HIGIG2_CLASSIFICATION] = {
+ .name = "classification",
+ .help = "matches classification of higig2 header",
+ .next = NEXT(item_higig2, NEXT_ENTRY(UNSIGNED), item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_higig2_hdr,
+ hdr.ppt1.classification)),
+ },
+ [ITEM_HIGIG2_VID] = {
+ .name = "vid",
+ .help = "matches vid of higig2 header",
+ .next = NEXT(item_higig2, NEXT_ENTRY(UNSIGNED), item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_higig2_hdr,
+ hdr.ppt1.vid)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -101,7 +101,8 @@ The public API headers are grouped by topics:
[GSO] (@ref rte_gso.h),
[frag/reass] (@ref rte_ip_frag.h),
[LPM IPv4 route] (@ref rte_lpm.h),
- [LPM IPv6 route] (@ref rte_lpm6.h)
+ [LPM IPv6 route] (@ref rte_lpm6.h),
+ [HIGIG] (@ref rte_higig.h)
- **QoS**:
[metering] (@ref rte_meter.h),
@@ -1289,6 +1289,14 @@ Matches a IP Authentication Header (RFC 4302).
- ``seq_num``: counter value increased by 1 on each packet sent.
- Default ``mask`` matches spi.
+Item: ``HIGIG2``
+^^^^^^^^^^^^^^^^^
+
+Matches a HIGIG2 header field. It is layer 2.5 protocol and used in
+Broadcom switches.
+
+- Default ``mask`` matches classification and vlan.
+
Actions
~~~~~~~
@@ -83,6 +83,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(NSH, sizeof(struct rte_flow_item_nsh)),
MK_FLOW_ITEM(IGMP, sizeof(struct rte_flow_item_igmp)),
MK_FLOW_ITEM(AH, sizeof(struct rte_flow_item_ah)),
+ MK_FLOW_ITEM(HIGIG2, sizeof(struct rte_flow_item_higig2_hdr)),
};
/** Generate flow_action[] entry. */
@@ -27,6 +27,7 @@
#include <rte_udp.h>
#include <rte_byteorder.h>
#include <rte_esp.h>
+#include <rte_higig.h>
#ifdef __cplusplus
extern "C" {
@@ -491,8 +492,36 @@ enum rte_flow_item_type {
*
*/
RTE_FLOW_ITEM_TYPE_AH,
+
+ /**
+ * Matches a HIGIG header.
+ * see struct rte_flow_item_higig2_hdr.
+ */
+ RTE_FLOW_ITEM_TYPE_HIGIG2,
};
+/**
+ *
+ * RTE_FLOW_ITEM_TYPE_HIGIG2
+ * Matches higig2 header
+ */
+RTE_STD_C11
+struct rte_flow_item_higig2_hdr {
+ struct rte_higig2_hdr hdr;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_HIGIG2. */
+#ifndef __cplusplus
+static const struct rte_flow_item_higig2_hdr rte_flow_item_higig2_hdr_mask = {
+ .hdr = {
+ .ppt1 = {
+ .classification = 0xffff,
+ .vid = 0xfff,
+ },
+ },
+};
+#endif
+
/**
* RTE_FLOW_ITEM_TYPE_ANY
*
@@ -21,6 +21,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_NET) += rte_arp.c
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h rte_udp.h rte_esp.h
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h rte_icmp.h rte_arp.h
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_gre.h rte_net.h
-SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_net_crc.h rte_mpls.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_net_crc.h rte_mpls.h rte_higig.h
include $(RTE_SDK)/mk/rte.lib.mk
@@ -14,7 +14,8 @@ headers = files('rte_ip.h',
'rte_gre.h',
'rte_net.h',
'rte_net_crc.h',
- 'rte_mpls.h')
+ 'rte_mpls.h',
+ 'rte_higig.h')
sources = files('rte_arp.c', 'rte_ether.c', 'rte_net.c', 'rte_net_crc.c')
deps += ['mbuf']
new file mode 100644
@@ -0,0 +1,145 @@
+
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ */
+
+#ifndef _RTE_HIGIG_H_
+#define _RTE_HIGIG_H_
+
+#include <stdint.h>
+#include <rte_byteorder.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ *
+ * higig2 frc header.
+ */
+struct rte_higig2_frc {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint32_t ksop:8;
+ uint32_t tc:4;
+ uint32_t mcst:1;
+ uint32_t resv:3;
+ uint32_t dst_modid:8;
+ uint32_t dst_pid:8;
+ uint32_t src_modid:8;
+ uint32_t src_pid:8;
+ uint32_t lbid:8;
+ uint32_t ppd_type:3;
+ uint32_t resv1:3;
+ uint32_t dp:2;
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint32_t ksop:8;
+ uint32_t resv:3;
+ uint32_t mcst:1;
+ uint32_t tc:4;
+ uint32_t dst_modid:8;
+ uint32_t dst_pid:8;
+ uint32_t src_modid:8;
+ uint32_t src_pid:8;
+ uint32_t lbid:8;
+ uint32_t dp:2;
+ uint32_t resv1:3;
+ uint32_t ppd_type:3;
+#endif
+};
+
+
+/**
+ *
+ * higig2 ppt type0 header
+ */
+struct rte_higig2_ppt_type0 {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint32_t mirror:1;
+ uint32_t mirror_done:1;
+ uint32_t mirror_only:1;
+ uint32_t ingress_tagged:1;
+ uint32_t dst_tgid:3;
+ uint32_t dst_t:1;
+ uint32_t vc_label2:4;
+ uint32_t label_present:1;
+ uint32_t l3:1;
+ uint32_t res:2;
+ uint32_t vc_label1:8;
+ uint32_t vc_label0:8;
+ uint32_t vid_high:8;
+ uint32_t vid_low:8;
+ uint32_t opc:3;
+ uint32_t res1:2;
+ uint32_t srce_t:1;
+ uint32_t pf:2;
+ uint32_t res2:5;
+ uint32_t hdr_ext_length:3;
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint32_t dst_t:1;
+ uint32_t dst_tgid:3;
+ uint32_t ingress_tagged:1;
+ uint32_t mirror_only:1;
+ uint32_t mirror_done:1;
+ uint32_t mirror:1;
+ uint32_t res:2;
+ uint32_t l3:1;
+ uint32_t label_present:1;
+ uint32_t vc_label2:4;
+ uint32_t vc_label1:8;
+ uint32_t vc_label0:8;
+ uint32_t vid_high:8;
+ uint32_t vid_low:8;
+ uint32_t pf:2;
+ uint32_t srce_t:1;
+ uint32_t res1:2;
+ uint32_t opc:3;
+ uint32_t hdr_ext_length:3;
+ uint32_t res2:5;
+#endif
+};
+
+
+/**
+ *
+ * higig2 ppt type1 header.
+ */
+RTE_STD_C11
+struct rte_higig2_ppt_type1 {
+ uint16_t classification;
+ uint16_t resv;
+ uint16_t vid;
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint16_t opcode:3;
+ uint16_t resv1:2;
+ uint16_t src_t:1;
+ uint16_t pfm:2;
+ uint16_t resv2:5;
+ uint16_t hdr_ext_len:3;
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint16_t pfm:2;
+ uint16_t src_t:1;
+ uint16_t resv1:2;
+ uint16_t opcode:3;
+ uint16_t hdr_ext_len:3;
+ uint16_t resv2:5;
+#endif
+};
+
+/**
+ *
+ * higig2 header
+ */
+RTE_STD_C11
+struct rte_higig2_hdr {
+ struct rte_higig2_frc fcr;
+ union {
+ struct rte_higig2_ppt_type0 ppt0;
+ struct rte_higig2_ppt_type1 ppt1;
+ };
+};
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_HIGIG_H_ */