[RFC,v2] ethdev: introduce GENEVE header extension item
Checks
Commit Message
The Geneve tunneling protocol is designed to allow
the user to specify some data context on the packet.
The header extension options is the mean intended
to present the user data. These ones are implemented
in TLV (Type-Length-Value) fashion, in order to
support these Geneve protocol feature we will
introduce the new item “rte_flow_item_geneve_option”
The support for new item will be added to testpmd
and include values and masks for the fields:
- class
- type
- data length
- data itself
The usage example:
"flow create 0 ingress pattern ipv4 / udp /
geneve / geneve_opt class is 102 type is 80
type mask ff data is 10002 data mask is
7fffffff / end actions drop / end "
New item will be added to testpmd to support
raw encap/decap action.
Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
---
lib/librte_ethdev/rte_flow.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
Comments
On 9/3/2020 8:39 AM, Shiri Kuzin wrote:
> The Geneve tunneling protocol is designed to allow
> the user to specify some data context on the packet.
> The header extension options is the mean intended
> to present the user data. These ones are implemented
> in TLV (Type-Length-Value) fashion, in order to
> support these Geneve protocol feature we will
> introduce the new item “rte_flow_item_geneve_option”
>
> The support for new item will be added to testpmd
> and include values and masks for the fields:
> - class
> - type
> - data length
> - data itself
>
> The usage example:
>
> "flow create 0 ingress pattern ipv4 / udp /
> geneve / geneve_opt class is 102 type is 80
> type mask ff data is 10002 data mask is
> 7fffffff / end actions drop / end "
>
> New item will be added to testpmd to support
> raw encap/decap action.
>
> Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
Hi Shiri,
Will there be a new version of the patch addressing the comments to previous
version:
http://inbox.dpdk.org/dev/MN2PR12MB42860D5ECF69BD6C78CECBF6D6200@MN2PR12MB4286.namprd12.prod.outlook.com/
Hi Ferruh,
Due to many changes in ethdev in this release and since this feature has lower priority, it was decided to postpone it for now.
We will consider having it as part of 21.02 release, I will send the new version then.
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Thursday, October 1, 2020 7:26 PM
> To: Shiri Kuzin <shirik@nvidia.com>; dev@dpdk.org
> Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-Contact-Adrien
> Mazarguil <adrien.mazarguil@6wind.com>; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [dpdk-dev] [RFC v2] ethdev: introduce GENEVE header
> extension item
>
> On 9/3/2020 8:39 AM, Shiri Kuzin wrote:
> > The Geneve tunneling protocol is designed to allow the user to specify
> > some data context on the packet.
> > The header extension options is the mean intended to present the user
> > data. These ones are implemented in TLV (Type-Length-Value) fashion,
> > in order to support these Geneve protocol feature we will introduce
> > the new item “rte_flow_item_geneve_option”
> >
> > The support for new item will be added to testpmd and include values
> > and masks for the fields:
> > - class
> > - type
> > - data length
> > - data itself
> >
> > The usage example:
> >
> > "flow create 0 ingress pattern ipv4 / udp / geneve / geneve_opt class
> > is 102 type is 80 type mask ff data is 10002 data mask is 7fffffff /
> > end actions drop / end "
> >
> > New item will be added to testpmd to support raw encap/decap action.
> >
> > Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
>
> Hi Shiri,
>
> Will there be a new version of the patch addressing the comments to
> previous
> version:
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox
> .dpdk.org%2Fdev%2FMN2PR12MB42860D5ECF69BD6C78CECBF6D6200%40M
> N2PR12MB4286.namprd12.prod.outlook.com%2F&data=02%7C01%7Cs
> hirik%40nvidia.com%7C467088ec8f354be6cc5208d86626d731%7C43083d1572
> 7340c1b7db39efd9ccc17a%7C0%7C0%7C637371664295102959&sdata=QE
> %2B0PQMqegeLmmtrMFz1FkV%2Fl%2FBMSOVRq5gcbtO6Z78%3D&res
> erved=0
On 10/5/2020 1:44 PM, Shiri Kuzin wrote:
> Hi Ferruh,
> Due to many changes in ethdev in this release and since this feature has lower priority, it was decided to postpone it for now.
> We will consider having it as part of 21.02 release, I will send the new version then.
>
Hi Shiri,
Thanks for the heads up. Please update the patchwork status accordingly.
Thanks,
ferruh
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Thursday, October 1, 2020 7:26 PM
>> To: Shiri Kuzin <shirik@nvidia.com>; dev@dpdk.org
>> Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-Contact-Adrien
>> Mazarguil <adrien.mazarguil@6wind.com>; Raslan Darawsheh
>> <rasland@nvidia.com>
>> Subject: Re: [dpdk-dev] [RFC v2] ethdev: introduce GENEVE header
>> extension item
>>
>> On 9/3/2020 8:39 AM, Shiri Kuzin wrote:
>>> The Geneve tunneling protocol is designed to allow the user to specify
>>> some data context on the packet.
>>> The header extension options is the mean intended to present the user
>>> data. These ones are implemented in TLV (Type-Length-Value) fashion,
>>> in order to support these Geneve protocol feature we will introduce
>>> the new item “rte_flow_item_geneve_option”
>>>
>>> The support for new item will be added to testpmd and include values
>>> and masks for the fields:
>>> - class
>>> - type
>>> - data length
>>> - data itself
>>>
>>> The usage example:
>>>
>>> "flow create 0 ingress pattern ipv4 / udp / geneve / geneve_opt class
>>> is 102 type is 80 type mask ff data is 10002 data mask is 7fffffff /
>>> end actions drop / end "
>>>
>>> New item will be added to testpmd to support raw encap/decap action.
>>>
>>> Signed-off-by: Shiri Kuzin <shirik@nvidia.com>
>>
>> Hi Shiri,
>>
>> Will there be a new version of the patch addressing the comments to
>> previous
>> version:
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox
>> .dpdk.org%2Fdev%2FMN2PR12MB42860D5ECF69BD6C78CECBF6D6200%40M
>> N2PR12MB4286.namprd12.prod.outlook.com%2F&data=02%7C01%7Cs
>> hirik%40nvidia.com%7C467088ec8f354be6cc5208d86626d731%7C43083d1572
>> 7340c1b7db39efd9ccc17a%7C0%7C0%7C637371664295102959&sdata=QE
>> %2B0PQMqegeLmmtrMFz1FkV%2Fl%2FBMSOVRq5gcbtO6Z78%3D&res
>> erved=0
>
@@ -537,6 +537,13 @@ enum rte_flow_item_type {
*/
RTE_FLOW_ITEM_TYPE_ECPRI,
+ /**
+ * Matches a GENEVE Variable Length Option.
+ *
+ * See struct rte_flow_item_geneve_option.
+ */
+ RTE_FLOW_ITEM_TYPE_GENEVE_OPTION,
+
};
/**
@@ -1097,6 +1104,24 @@ struct rte_flow_item_geneve {
#endif
/**
+ * RTE_FLOW_ITEM_TYPE_GENEVE_OPTION.
+ *
+ * Matches a GENEVE Variable Length Option
+ */
+struct rte_flow_item_geneve_option {
+ rte_be16_t option_class;
+ uint8_t option_type;
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t length:5;
+ uint8_t rsvd0:3;
+#else
+ uint8_t rsvd0:3;
+ uint8_t length:5;
+#endif
+ uint8_t data[];
+};
+
+/**
* RTE_FLOW_ITEM_TYPE_VXLAN_GPE (draft-ietf-nvo3-vxlan-gpe-05).
*
* Matches a VXLAN-GPE header.