DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
@ 2020-11-23 13:40 Ferruh Yigit
  2020-11-23 13:50 ` Andrew Rybchenko
  2020-11-24 13:15 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
  0 siblings, 2 replies; 13+ messages in thread
From: Ferruh Yigit @ 2020-11-23 13:40 UTC (permalink / raw)
  To: Ray Kinsella, Neil Horman
  Cc: Ferruh Yigit, dev, Thomas Monjalon, Andrew Rybchenko, Ori Kam

Proposing to replace protocol header fields in the ``rte_flow_item_*``
structures with the protocol structs, like:

Current ``struct rte_flow_item_eth``,

struct rte_flow_item_eth {
	struct rte_ether_addr dst;
	struct rte_ether_addr src;
	rte_be16_t type;
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

will become

struct rte_flow_item_eth {
	struct rte_ether_hdr hdr;
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

This is both for documenting the intention and to be sure
``rte_flow_item_*`` always starts with complete protocol header.

Already many ``rte_flow_item_*`` structs implemented to have protocol
struct, target is convert all to this usage.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Thomas Monjalon <thomas@monjalon.net>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: Ori Kam <orika@nvidia.com>
---
 doc/guides/rel_notes/deprecation.rst | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 96986fabd598..a2fa0c196472 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -88,6 +88,13 @@ Deprecation Notices
   will be limited to maximum 256 queues.
   Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
 
+* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
+  should start with relevant protocol header.
+  Some matching pattern structures implements this by duplicating protocol header
+  fields in the struct. To clarify the intention and to be sure protocol header
+  is intact, will replace those fields with relevant protocol header struct.
+  Target is v21.02 release and this should not change the ABI.
+
 * sched: To allow more traffic classes, flexible mapping of pipe queues to
   traffic classes, and subport level configuration of pipes and queues
   changes will be made to macros, data structures and API functions defined
-- 
2.26.2


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-23 13:40 [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes Ferruh Yigit
@ 2020-11-23 13:50 ` Andrew Rybchenko
  2020-11-23 14:17   ` Ferruh Yigit
  2020-11-24 13:15 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
  1 sibling, 1 reply; 13+ messages in thread
From: Andrew Rybchenko @ 2020-11-23 13:50 UTC (permalink / raw)
  To: Ferruh Yigit, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam

On 11/23/20 4:40 PM, Ferruh Yigit wrote:
> Proposing to replace protocol header fields in the ``rte_flow_item_*``
> structures with the protocol structs, like:
> 
> Current ``struct rte_flow_item_eth``,
> 
> struct rte_flow_item_eth {
> 	struct rte_ether_addr dst;
> 	struct rte_ether_addr src;
> 	rte_be16_t type;
> 	uint32_t has_vlan:1;
> 	uint32_t reserved:31;
> }
> 
> will become
> 
> struct rte_flow_item_eth {
> 	struct rte_ether_hdr hdr;
> 	uint32_t has_vlan:1;
> 	uint32_t reserved:31;
> }
> 
> This is both for documenting the intention and to be sure
> ``rte_flow_item_*`` always starts with complete protocol header.
> 
> Already many ``rte_flow_item_*`` structs implemented to have protocol
> struct, target is convert all to this usage.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

a minor note below

> ---
> Cc: Thomas Monjalon <thomas@monjalon.net>
> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Cc: Ori Kam <orika@nvidia.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 96986fabd598..a2fa0c196472 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -88,6 +88,13 @@ Deprecation Notices
>    will be limited to maximum 256 queues.
>    Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
>  
> +* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
> +  should start with relevant protocol header.
> +  Some matching pattern structures implements this by duplicating protocol header
> +  fields in the struct. To clarify the intention and to be sure protocol header
> +  is intact, will replace those fields with relevant protocol header struct.
> +  Target is v21.02 release and this should not change the ABI.
> +
>  * sched: To allow more traffic classes, flexible mapping of pipe queues to
>    traffic classes, and subport level configuration of pipes and queues
>    changes will be made to macros, data structures and API functions defined
> 

Just want to highlight that even API could be kept using
unnamed union for hdr and unnamed structure for existing
protocol header fields.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-23 13:50 ` Andrew Rybchenko
@ 2020-11-23 14:17   ` Ferruh Yigit
  2020-11-23 14:25     ` Andrew Rybchenko
  0 siblings, 1 reply; 13+ messages in thread
From: Ferruh Yigit @ 2020-11-23 14:17 UTC (permalink / raw)
  To: Andrew Rybchenko, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam

On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>> structures with the protocol structs, like:
>>
>> Current ``struct rte_flow_item_eth``,
>>
>> struct rte_flow_item_eth {
>> 	struct rte_ether_addr dst;
>> 	struct rte_ether_addr src;
>> 	rte_be16_t type;
>> 	uint32_t has_vlan:1;
>> 	uint32_t reserved:31;
>> }
>>
>> will become
>>
>> struct rte_flow_item_eth {
>> 	struct rte_ether_hdr hdr;
>> 	uint32_t has_vlan:1;
>> 	uint32_t reserved:31;
>> }
>>
>> This is both for documenting the intention and to be sure
>> ``rte_flow_item_*`` always starts with complete protocol header.
>>
>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>> struct, target is convert all to this usage.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> 
> a minor note below
> 
>> ---
>> Cc: Thomas Monjalon <thomas@monjalon.net>
>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Cc: Ori Kam <orika@nvidia.com>
>> ---
>>   doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>> index 96986fabd598..a2fa0c196472 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -88,6 +88,13 @@ Deprecation Notices
>>     will be limited to maximum 256 queues.
>>     Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
>>   
>> +* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
>> +  should start with relevant protocol header.
>> +  Some matching pattern structures implements this by duplicating protocol header
>> +  fields in the struct. To clarify the intention and to be sure protocol header
>> +  is intact, will replace those fields with relevant protocol header struct.
>> +  Target is v21.02 release and this should not change the ABI.
>> +
>>   * sched: To allow more traffic classes, flexible mapping of pipe queues to
>>     traffic classes, and subport level configuration of pipes and queues
>>     changes will be made to macros, data structures and API functions defined
>>
> 
> Just want to highlight that even API could be kept using
> unnamed union for hdr and unnamed structure for existing
> protocol header fields.
> 

Then we may never clean the protocol header fields out of it,
yes this will impact the user but I believe the impact is small and trivial,
I prefer replacing fields with protocol struct.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-23 14:17   ` Ferruh Yigit
@ 2020-11-23 14:25     ` Andrew Rybchenko
  2020-11-23 15:51       ` Ferruh Yigit
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Rybchenko @ 2020-11-23 14:25 UTC (permalink / raw)
  To: Ferruh Yigit, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam

On 11/23/20 5:17 PM, Ferruh Yigit wrote:
> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>>> structures with the protocol structs, like:
>>>
>>> Current ``struct rte_flow_item_eth``,
>>>
>>> struct rte_flow_item_eth {
>>>     struct rte_ether_addr dst;
>>>     struct rte_ether_addr src;
>>>     rte_be16_t type;
>>>     uint32_t has_vlan:1;
>>>     uint32_t reserved:31;
>>> }
>>>
>>> will become
>>>
>>> struct rte_flow_item_eth {
>>>     struct rte_ether_hdr hdr;
>>>     uint32_t has_vlan:1;
>>>     uint32_t reserved:31;
>>> }
>>>
>>> This is both for documenting the intention and to be sure
>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>
>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>>> struct, target is convert all to this usage.
>>>
>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>
>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>
>> a minor note below
>>
>>> ---
>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>> Cc: Ori Kam <orika@nvidia.com>
>>> ---
>>>   doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>> b/doc/guides/rel_notes/deprecation.rst
>>> index 96986fabd598..a2fa0c196472 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>     will be limited to maximum 256 queues.
>>>     Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
>>> removed.
>>>   +* ethdev: The flow API matching pattern structures, ``struct
>>> rte_flow_item_*``,
>>> +  should start with relevant protocol header.
>>> +  Some matching pattern structures implements this by duplicating
>>> protocol header
>>> +  fields in the struct. To clarify the intention and to be sure
>>> protocol header
>>> +  is intact, will replace those fields with relevant protocol
>>> header struct.
>>> +  Target is v21.02 release and this should not change the ABI.
>>> +
>>>   * sched: To allow more traffic classes, flexible mapping of pipe
>>> queues to
>>>     traffic classes, and subport level configuration of pipes and
>>> queues
>>>     changes will be made to macros, data structures and API
>>> functions defined
>>>
>>
>> Just want to highlight that even API could be kept using
>> unnamed union for hdr and unnamed structure for existing
>> protocol header fields.
>>
>
> Then we may never clean the protocol header fields out of it,
> yes this will impact the user but I believe the impact is small and
> trivial,
> I prefer replacing fields with protocol struct.

The problem that API breakages are bad and, for example, OvS uses these
fields.

May be API breakage should be postponed to 21.11?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-23 14:25     ` Andrew Rybchenko
@ 2020-11-23 15:51       ` Ferruh Yigit
  2020-11-24 11:43         ` Ori Kam
  0 siblings, 1 reply; 13+ messages in thread
From: Ferruh Yigit @ 2020-11-23 15:51 UTC (permalink / raw)
  To: Andrew Rybchenko, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam

On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>>>> structures with the protocol structs, like:
>>>>
>>>> Current ``struct rte_flow_item_eth``,
>>>>
>>>> struct rte_flow_item_eth {
>>>>      struct rte_ether_addr dst;
>>>>      struct rte_ether_addr src;
>>>>      rte_be16_t type;
>>>>      uint32_t has_vlan:1;
>>>>      uint32_t reserved:31;
>>>> }
>>>>
>>>> will become
>>>>
>>>> struct rte_flow_item_eth {
>>>>      struct rte_ether_hdr hdr;
>>>>      uint32_t has_vlan:1;
>>>>      uint32_t reserved:31;
>>>> }
>>>>
>>>> This is both for documenting the intention and to be sure
>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>
>>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>>>> struct, target is convert all to this usage.
>>>>
>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>
>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>
>>> a minor note below
>>>
>>>> ---
>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>> Cc: Ori Kam <orika@nvidia.com>
>>>> ---
>>>>    doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>    1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>> b/doc/guides/rel_notes/deprecation.rst
>>>> index 96986fabd598..a2fa0c196472 100644
>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>>      will be limited to maximum 256 queues.
>>>>      Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
>>>> removed.
>>>>    +* ethdev: The flow API matching pattern structures, ``struct
>>>> rte_flow_item_*``,
>>>> +  should start with relevant protocol header.
>>>> +  Some matching pattern structures implements this by duplicating
>>>> protocol header
>>>> +  fields in the struct. To clarify the intention and to be sure
>>>> protocol header
>>>> +  is intact, will replace those fields with relevant protocol
>>>> header struct.
>>>> +  Target is v21.02 release and this should not change the ABI.
>>>> +
>>>>    * sched: To allow more traffic classes, flexible mapping of pipe
>>>> queues to
>>>>      traffic classes, and subport level configuration of pipes and
>>>> queues
>>>>      changes will be made to macros, data structures and API
>>>> functions defined
>>>>
>>>
>>> Just want to highlight that even API could be kept using
>>> unnamed union for hdr and unnamed structure for existing
>>> protocol header fields.
>>>
>>
>> Then we may never clean the protocol header fields out of it,
>> yes this will impact the user but I believe the impact is small and
>> trivial,
>> I prefer replacing fields with protocol struct.
> 
> The problem that API breakages are bad and, for example, OvS uses these
> fields.
> 
> May be API breakage should be postponed to 21.11?
> 

Agree but it is not as bad as ABI break, if user is already compiling their 
code, it is not too bad to adjust the struct for changes, and the changes are 
straightforward.

But if, somehow, application needs to support multiple version of the DPDK it 
can be headache.

We may go with your suggestion until 21.11, and do the cleanup on 21.11, will it 
work?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-23 15:51       ` Ferruh Yigit
@ 2020-11-24 11:43         ` Ori Kam
  2020-11-24 12:56           ` Ferruh Yigit
  0 siblings, 1 reply; 13+ messages in thread
From: Ori Kam @ 2020-11-24 11:43 UTC (permalink / raw)
  To: Ferruh Yigit, Andrew Rybchenko, Ray Kinsella, Neil Horman
  Cc: dev, NBU-Contact-Thomas Monjalon

Hi

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Monday, November 23, 2020 5:51 PM
> Subject: Re: [PATCH] doc: announce flow API matching pattern struct changes
> 
> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
> > On 11/23/20 5:17 PM, Ferruh Yigit wrote:
> >> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
> >>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
> >>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
> >>>> structures with the protocol structs, like:
> >>>>
> >>>> Current ``struct rte_flow_item_eth``,
> >>>>
> >>>> struct rte_flow_item_eth {
> >>>>      struct rte_ether_addr dst;
> >>>>      struct rte_ether_addr src;
> >>>>      rte_be16_t type;
> >>>>      uint32_t has_vlan:1;
> >>>>      uint32_t reserved:31;
> >>>> }
> >>>>
> >>>> will become
> >>>>
> >>>> struct rte_flow_item_eth {
> >>>>      struct rte_ether_hdr hdr;
> >>>>      uint32_t has_vlan:1;
> >>>>      uint32_t reserved:31;
> >>>> }
> >>>>
> >>>> This is both for documenting the intention and to be sure
> >>>> ``rte_flow_item_*`` always starts with complete protocol header.
> >>>>
> >>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
> >>>> struct, target is convert all to this usage.
> >>>>
> >>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >>>
> >>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >>>
> >>> a minor note below
> >>>
> >>>> ---
> >>>> Cc: Thomas Monjalon <thomas@monjalon.net>
> >>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >>>> Cc: Ori Kam <orika@nvidia.com>
> >>>> ---
> >>>>    doc/guides/rel_notes/deprecation.rst | 7 +++++++
> >>>>    1 file changed, 7 insertions(+)
> >>>>
> >>>> diff --git a/doc/guides/rel_notes/deprecation.rst
> >>>> b/doc/guides/rel_notes/deprecation.rst
> >>>> index 96986fabd598..a2fa0c196472 100644
> >>>> --- a/doc/guides/rel_notes/deprecation.rst
> >>>> +++ b/doc/guides/rel_notes/deprecation.rst
> >>>> @@ -88,6 +88,13 @@ Deprecation Notices
> >>>>      will be limited to maximum 256 queues.
> >>>>      Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
> >>>> removed.
> >>>>    +* ethdev: The flow API matching pattern structures, ``struct
> >>>> rte_flow_item_*``,
> >>>> +  should start with relevant protocol header.
> >>>> +  Some matching pattern structures implements this by duplicating
> >>>> protocol header
> >>>> +  fields in the struct. To clarify the intention and to be sure
> >>>> protocol header
> >>>> +  is intact, will replace those fields with relevant protocol
> >>>> header struct.
> >>>> +  Target is v21.02 release and this should not change the ABI.
> >>>> +
> >>>>    * sched: To allow more traffic classes, flexible mapping of pipe
> >>>> queues to
> >>>>      traffic classes, and subport level configuration of pipes and
> >>>> queues
> >>>>      changes will be made to macros, data structures and API
> >>>> functions defined
> >>>>
> >>>
> >>> Just want to highlight that even API could be kept using
> >>> unnamed union for hdr and unnamed structure for existing
> >>> protocol header fields.
> >>>
> >>
> >> Then we may never clean the protocol header fields out of it,
> >> yes this will impact the user but I believe the impact is small and
> >> trivial,
> >> I prefer replacing fields with protocol struct.
> >
> > The problem that API breakages are bad and, for example, OvS uses these
> > fields.
> >
> > May be API breakage should be postponed to 21.11?
> >
> 
> Agree but it is not as bad as ABI break, if user is already compiling their
> code, it is not too bad to adjust the struct for changes, and the changes are
> straightforward.
> 
I'm not sure which is worse ABI or API, API is more straight forward but all apps must be modified,
while ABI is hidden and happens only in rare cases.
In a addition it may result in large number of changes (simple but large number)

> But if, somehow, application needs to support multiple version of the DPDK it
> can be headache.
> 

Agree, 

> We may go with your suggestion until 21.11, and do the cleanup on 21.11, will
> it
> work?
+1 also when considering my next line,

One more point to consider what happens to struct that are not according to spec,
for example mpls, geneve where the struct is different than the item.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-24 11:43         ` Ori Kam
@ 2020-11-24 12:56           ` Ferruh Yigit
  2020-11-24 13:00             ` Andrew Rybchenko
  0 siblings, 1 reply; 13+ messages in thread
From: Ferruh Yigit @ 2020-11-24 12:56 UTC (permalink / raw)
  To: Ori Kam, Andrew Rybchenko, Ray Kinsella, Neil Horman
  Cc: dev, NBU-Contact-Thomas Monjalon

On 11/24/2020 11:43 AM, Ori Kam wrote:
> Hi
> 
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Monday, November 23, 2020 5:51 PM
>> Subject: Re: [PATCH] doc: announce flow API matching pattern struct changes
>>
>> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
>>> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>>>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>>>>>> structures with the protocol structs, like:
>>>>>>
>>>>>> Current ``struct rte_flow_item_eth``,
>>>>>>
>>>>>> struct rte_flow_item_eth {
>>>>>>       struct rte_ether_addr dst;
>>>>>>       struct rte_ether_addr src;
>>>>>>       rte_be16_t type;
>>>>>>       uint32_t has_vlan:1;
>>>>>>       uint32_t reserved:31;
>>>>>> }
>>>>>>
>>>>>> will become
>>>>>>
>>>>>> struct rte_flow_item_eth {
>>>>>>       struct rte_ether_hdr hdr;
>>>>>>       uint32_t has_vlan:1;
>>>>>>       uint32_t reserved:31;
>>>>>> }
>>>>>>
>>>>>> This is both for documenting the intention and to be sure
>>>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>>>
>>>>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>>>>>> struct, target is convert all to this usage.
>>>>>>
>>>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>
>>>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>
>>>>> a minor note below
>>>>>
>>>>>> ---
>>>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>> Cc: Ori Kam <orika@nvidia.com>
>>>>>> ---
>>>>>>     doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>>     1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>> index 96986fabd598..a2fa0c196472 100644
>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>>>>       will be limited to maximum 256 queues.
>>>>>>       Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
>>>>>> removed.
>>>>>>     +* ethdev: The flow API matching pattern structures, ``struct
>>>>>> rte_flow_item_*``,
>>>>>> +  should start with relevant protocol header.
>>>>>> +  Some matching pattern structures implements this by duplicating
>>>>>> protocol header
>>>>>> +  fields in the struct. To clarify the intention and to be sure
>>>>>> protocol header
>>>>>> +  is intact, will replace those fields with relevant protocol
>>>>>> header struct.
>>>>>> +  Target is v21.02 release and this should not change the ABI.
>>>>>> +
>>>>>>     * sched: To allow more traffic classes, flexible mapping of pipe
>>>>>> queues to
>>>>>>       traffic classes, and subport level configuration of pipes and
>>>>>> queues
>>>>>>       changes will be made to macros, data structures and API
>>>>>> functions defined
>>>>>>
>>>>>
>>>>> Just want to highlight that even API could be kept using
>>>>> unnamed union for hdr and unnamed structure for existing
>>>>> protocol header fields.
>>>>>
>>>>
>>>> Then we may never clean the protocol header fields out of it,
>>>> yes this will impact the user but I believe the impact is small and
>>>> trivial,
>>>> I prefer replacing fields with protocol struct.
>>>
>>> The problem that API breakages are bad and, for example, OvS uses these
>>> fields.
>>>
>>> May be API breakage should be postponed to 21.11?
>>>
>>
>> Agree but it is not as bad as ABI break, if user is already compiling their
>> code, it is not too bad to adjust the struct for changes, and the changes are
>> straightforward.
>>
> I'm not sure which is worse ABI or API, API is more straight forward but all apps must be modified,
> while ABI is hidden and happens only in rare cases.
> In a addition it may result in large number of changes (simple but large number)
> 
>> But if, somehow, application needs to support multiple version of the DPDK it
>> can be headache.
>>
> 
> Agree,
> 
>> We may go with your suggestion until 21.11, and do the cleanup on 21.11, will
>> it
>> work?
> +1 also when considering my next line,
> 
> One more point to consider what happens to struct that are not according to spec,
> for example mpls, geneve where the struct is different than the item.
> 

At least for mpls & geneve, the ABI still looks same so change is still 
possible, but a few fields seems merged which means the change will require more 
updates in the user application and the drivers. Anyway, agree to postpone 
change to the 21.11.

I will send a v2.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-24 12:56           ` Ferruh Yigit
@ 2020-11-24 13:00             ` Andrew Rybchenko
  2020-11-24 13:01               ` Andrew Rybchenko
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Rybchenko @ 2020-11-24 13:00 UTC (permalink / raw)
  To: Ferruh Yigit, Ori Kam, Ray Kinsella, Neil Horman
  Cc: dev, NBU-Contact-Thomas Monjalon

On 11/24/20 3:56 PM, Ferruh Yigit wrote:
> On 11/24/2020 11:43 AM, Ori Kam wrote:
>> Hi
>>
>>> -----Original Message-----
>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>> Sent: Monday, November 23, 2020 5:51 PM
>>> Subject: Re: [PATCH] doc: announce flow API matching pattern struct
>>> changes
>>>
>>> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
>>>> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>>>>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>>>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>>>>> Proposing to replace protocol header fields in the
>>>>>>> ``rte_flow_item_*``
>>>>>>> structures with the protocol structs, like:
>>>>>>>
>>>>>>> Current ``struct rte_flow_item_eth``,
>>>>>>>
>>>>>>> struct rte_flow_item_eth {
>>>>>>>       struct rte_ether_addr dst;
>>>>>>>       struct rte_ether_addr src;
>>>>>>>       rte_be16_t type;
>>>>>>>       uint32_t has_vlan:1;
>>>>>>>       uint32_t reserved:31;
>>>>>>> }
>>>>>>>
>>>>>>> will become
>>>>>>>
>>>>>>> struct rte_flow_item_eth {
>>>>>>>       struct rte_ether_hdr hdr;
>>>>>>>       uint32_t has_vlan:1;
>>>>>>>       uint32_t reserved:31;
>>>>>>> }
>>>>>>>
>>>>>>> This is both for documenting the intention and to be sure
>>>>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>>>>
>>>>>>> Already many ``rte_flow_item_*`` structs implemented to have
>>>>>>> protocol
>>>>>>> struct, target is convert all to this usage.
>>>>>>>
>>>>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>
>>>>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>
>>>>>> a minor note below
>>>>>>
>>>>>>> ---
>>>>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>> Cc: Ori Kam <orika@nvidia.com>
>>>>>>> ---
>>>>>>>     doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>>>     1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>>> index 96986fabd598..a2fa0c196472 100644
>>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>>>>>       will be limited to maximum 256 queues.
>>>>>>>       Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS``
>>>>>>> will be
>>>>>>> removed.
>>>>>>>     +* ethdev: The flow API matching pattern structures, ``struct
>>>>>>> rte_flow_item_*``,
>>>>>>> +  should start with relevant protocol header.
>>>>>>> +  Some matching pattern structures implements this by duplicating
>>>>>>> protocol header
>>>>>>> +  fields in the struct. To clarify the intention and to be sure
>>>>>>> protocol header
>>>>>>> +  is intact, will replace those fields with relevant protocol
>>>>>>> header struct.
>>>>>>> +  Target is v21.02 release and this should not change the ABI.
>>>>>>> +
>>>>>>>     * sched: To allow more traffic classes, flexible mapping of
>>>>>>> pipe
>>>>>>> queues to
>>>>>>>       traffic classes, and subport level configuration of pipes and
>>>>>>> queues
>>>>>>>       changes will be made to macros, data structures and API
>>>>>>> functions defined
>>>>>>>
>>>>>>
>>>>>> Just want to highlight that even API could be kept using
>>>>>> unnamed union for hdr and unnamed structure for existing
>>>>>> protocol header fields.
>>>>>>
>>>>>
>>>>> Then we may never clean the protocol header fields out of it,
>>>>> yes this will impact the user but I believe the impact is small and
>>>>> trivial,
>>>>> I prefer replacing fields with protocol struct.
>>>>
>>>> The problem that API breakages are bad and, for example, OvS uses
>>>> these
>>>> fields.
>>>>
>>>> May be API breakage should be postponed to 21.11?
>>>>
>>>
>>> Agree but it is not as bad as ABI break, if user is already
>>> compiling their
>>> code, it is not too bad to adjust the struct for changes, and the
>>> changes are
>>> straightforward.
>>>
>> I'm not sure which is worse ABI or API, API is more straight forward
>> but all apps must be modified,
>> while ABI is hidden and happens only in rare cases.
>> In a addition it may result in large number of changes (simple but
>> large number)
>>
>>> But if, somehow, application needs to support multiple version of
>>> the DPDK it
>>> can be headache.
>>>
>>
>> Agree,
>>
>>> We may go with your suggestion until 21.11, and do the cleanup on
>>> 21.11, will
>>> it
>>> work?
>> +1 also when considering my next line,
>>
>> One more point to consider what happens to struct that are not
>> according to spec,
>> for example mpls, geneve where the struct is different than the item.
>>
>
> At least for mpls & geneve, the ABI still looks same so change is
> still possible, but a few fields seems merged which means the change
> will require more updates in the user application and the drivers.
> Anyway, agree to postpone change to the 21.11.
>
> I will send a v2.

I hope it is still possible to add hdr fields without ABI/ABI breakage
in 20.02.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
  2020-11-24 13:00             ` Andrew Rybchenko
@ 2020-11-24 13:01               ` Andrew Rybchenko
  0 siblings, 0 replies; 13+ messages in thread
From: Andrew Rybchenko @ 2020-11-24 13:01 UTC (permalink / raw)
  To: Ferruh Yigit, Ori Kam, Ray Kinsella, Neil Horman
  Cc: dev, NBU-Contact-Thomas Monjalon

On 11/24/20 4:00 PM, Andrew Rybchenko wrote:
> On 11/24/20 3:56 PM, Ferruh Yigit wrote:
>> On 11/24/2020 11:43 AM, Ori Kam wrote:
>>> Hi
>>>
>>>> -----Original Message-----
>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>> Sent: Monday, November 23, 2020 5:51 PM
>>>> Subject: Re: [PATCH] doc: announce flow API matching pattern struct
>>>> changes
>>>>
>>>> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
>>>>> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>>>>>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>>>>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>>>>>> Proposing to replace protocol header fields in the
>>>>>>>> ``rte_flow_item_*``
>>>>>>>> structures with the protocol structs, like:
>>>>>>>>
>>>>>>>> Current ``struct rte_flow_item_eth``,
>>>>>>>>
>>>>>>>> struct rte_flow_item_eth {
>>>>>>>>       struct rte_ether_addr dst;
>>>>>>>>       struct rte_ether_addr src;
>>>>>>>>       rte_be16_t type;
>>>>>>>>       uint32_t has_vlan:1;
>>>>>>>>       uint32_t reserved:31;
>>>>>>>> }
>>>>>>>>
>>>>>>>> will become
>>>>>>>>
>>>>>>>> struct rte_flow_item_eth {
>>>>>>>>       struct rte_ether_hdr hdr;
>>>>>>>>       uint32_t has_vlan:1;
>>>>>>>>       uint32_t reserved:31;
>>>>>>>> }
>>>>>>>>
>>>>>>>> This is both for documenting the intention and to be sure
>>>>>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>>>>>
>>>>>>>> Already many ``rte_flow_item_*`` structs implemented to have
>>>>>>>> protocol
>>>>>>>> struct, target is convert all to this usage.
>>>>>>>>
>>>>>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>>
>>>>>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>>
>>>>>>> a minor note below
>>>>>>>
>>>>>>>> ---
>>>>>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>>> Cc: Ori Kam <orika@nvidia.com>
>>>>>>>> ---
>>>>>>>>     doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>>>>     1 file changed, 7 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>>>> index 96986fabd598..a2fa0c196472 100644
>>>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>>>>>>       will be limited to maximum 256 queues.
>>>>>>>>       Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS``
>>>>>>>> will be
>>>>>>>> removed.
>>>>>>>>     +* ethdev: The flow API matching pattern structures, ``struct
>>>>>>>> rte_flow_item_*``,
>>>>>>>> +  should start with relevant protocol header.
>>>>>>>> +  Some matching pattern structures implements this by duplicating
>>>>>>>> protocol header
>>>>>>>> +  fields in the struct. To clarify the intention and to be sure
>>>>>>>> protocol header
>>>>>>>> +  is intact, will replace those fields with relevant protocol
>>>>>>>> header struct.
>>>>>>>> +  Target is v21.02 release and this should not change the ABI.
>>>>>>>> +
>>>>>>>>     * sched: To allow more traffic classes, flexible mapping of
>>>>>>>> pipe
>>>>>>>> queues to
>>>>>>>>       traffic classes, and subport level configuration of pipes and
>>>>>>>> queues
>>>>>>>>       changes will be made to macros, data structures and API
>>>>>>>> functions defined
>>>>>>>>
>>>>>>>
>>>>>>> Just want to highlight that even API could be kept using
>>>>>>> unnamed union for hdr and unnamed structure for existing
>>>>>>> protocol header fields.
>>>>>>>
>>>>>>
>>>>>> Then we may never clean the protocol header fields out of it,
>>>>>> yes this will impact the user but I believe the impact is small and
>>>>>> trivial,
>>>>>> I prefer replacing fields with protocol struct.
>>>>>
>>>>> The problem that API breakages are bad and, for example, OvS uses
>>>>> these
>>>>> fields.
>>>>>
>>>>> May be API breakage should be postponed to 21.11?
>>>>>
>>>>
>>>> Agree but it is not as bad as ABI break, if user is already
>>>> compiling their
>>>> code, it is not too bad to adjust the struct for changes, and the
>>>> changes are
>>>> straightforward.
>>>>
>>> I'm not sure which is worse ABI or API, API is more straight forward
>>> but all apps must be modified,
>>> while ABI is hidden and happens only in rare cases.
>>> In a addition it may result in large number of changes (simple but
>>> large number)
>>>
>>>> But if, somehow, application needs to support multiple version of
>>>> the DPDK it
>>>> can be headache.
>>>>
>>>
>>> Agree,
>>>
>>>> We may go with your suggestion until 21.11, and do the cleanup on
>>>> 21.11, will
>>>> it
>>>> work?
>>> +1 also when considering my next line,
>>>
>>> One more point to consider what happens to struct that are not
>>> according to spec,
>>> for example mpls, geneve where the struct is different than the item.
>>>
>>
>> At least for mpls & geneve, the ABI still looks same so change is
>> still possible, but a few fields seems merged which means the change
>> will require more updates in the user application and the drivers.
>> Anyway, agree to postpone change to the 21.11.
>>
>> I will send a v2.
> 
> I hope it is still possible to add hdr fields without ABI/ABI breakage
> in 20.02.
> 

21.02 of course


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [dpdk-dev] [PATCH v2] doc: announce flow API matching pattern struct changes
  2020-11-23 13:40 [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes Ferruh Yigit
  2020-11-23 13:50 ` Andrew Rybchenko
@ 2020-11-24 13:15 ` Ferruh Yigit
  2020-11-24 14:29   ` Ajit Khaparde
  2020-11-27 16:16   ` Bruce Richardson
  1 sibling, 2 replies; 13+ messages in thread
From: Ferruh Yigit @ 2020-11-24 13:15 UTC (permalink / raw)
  To: Ray Kinsella, Neil Horman
  Cc: Ferruh Yigit, dev, Andrew Rybchenko, Thomas Monjalon, Ori Kam

Proposing to replace protocol header fields in the ``rte_flow_item_*``
structures with the protocol structs.

This is both for documenting the intention and to be sure
``rte_flow_item_*`` always starts with complete protocol header.

Change will be done in two steps, at first step in v21.02 release,
protocol header struct will be added as union, for example:

Current ``struct rte_flow_item_eth``,

struct rte_flow_item_eth {
	struct rte_ether_addr dst;
	struct rte_ether_addr src;
	rte_be16_t type;
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

will become in v21.02:

__extension__
struct rte_flow_item_eth {
	union {
		struct {
			struct rte_ether_addr dst;
			struct rte_ether_addr src;
			rte_be16_t type;
		};
		struct rte_ether_hdr hdr;
	};
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

After this point usage should switch to 'hdr' struct.

And in the second step, in the v21.11 LTS release the protocol fields
will be removed, and the struct will become:

struct rte_flow_item_eth {
	struct rte_ether_hdr hdr;
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

Already many ``rte_flow_item_*`` structures implemented to have protocol
struct, target is convert all to this usage.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
Cc: Thomas Monjalon <thomas@monjalon.net>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: Ori Kam <orika@nvidia.com>

v2:
* Defer actual cleanup to the v21.11 LTS release
---
 doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 96986fabd598..90b6fbc9548c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -88,6 +88,16 @@ Deprecation Notices
   will be limited to maximum 256 queues.
   Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
 
+* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
+  should start with relevant protocol header.
+  Some matching pattern structures implements this by duplicating protocol header
+  fields in the struct. To clarify the intention and to be sure protocol header
+  is intact, will replace those fields with relevant protocol header struct.
+  In v21.02 both individual protocol header fields and the protocol header struct
+  will be added as union, target is switch usage to the protocol header by time.
+  In v21.11 LTS, protocol header fields will be cleaned and only protocol header
+  struct will remain.
+
 * sched: To allow more traffic classes, flexible mapping of pipe queues to
   traffic classes, and subport level configuration of pipes and queues
   changes will be made to macros, data structures and API functions defined
-- 
2.26.2


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH v2] doc: announce flow API matching pattern struct changes
  2020-11-24 13:15 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
@ 2020-11-24 14:29   ` Ajit Khaparde
  2020-11-27 17:56     ` Thomas Monjalon
  2020-11-27 16:16   ` Bruce Richardson
  1 sibling, 1 reply; 13+ messages in thread
From: Ajit Khaparde @ 2020-11-24 14:29 UTC (permalink / raw)
  To: Ferruh Yigit
  Cc: Ray Kinsella, Neil Horman, dpdk-dev, Andrew Rybchenko,
	Thomas Monjalon, Ori Kam

On Tue, Nov 24, 2020 at 5:15 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> Proposing to replace protocol header fields in the ``rte_flow_item_*``
> structures with the protocol structs.
>
> This is both for documenting the intention and to be sure
> ``rte_flow_item_*`` always starts with complete protocol header.
>
> Change will be done in two steps, at first step in v21.02 release,
> protocol header struct will be added as union, for example:
>
> Current ``struct rte_flow_item_eth``,
>
> struct rte_flow_item_eth {
>         struct rte_ether_addr dst;
>         struct rte_ether_addr src;
>         rte_be16_t type;
>         uint32_t has_vlan:1;
>         uint32_t reserved:31;
> }
>
> will become in v21.02:
>
> __extension__
> struct rte_flow_item_eth {
>         union {
>                 struct {
>                         struct rte_ether_addr dst;
>                         struct rte_ether_addr src;
>                         rte_be16_t type;
>                 };
>                 struct rte_ether_hdr hdr;
>         };
>         uint32_t has_vlan:1;
>         uint32_t reserved:31;
> }
>
> After this point usage should switch to 'hdr' struct.
>
> And in the second step, in the v21.11 LTS release the protocol fields
> will be removed, and the struct will become:
>
> struct rte_flow_item_eth {
>         struct rte_ether_hdr hdr;
>         uint32_t has_vlan:1;
>         uint32_t reserved:31;
> }
>
> Already many ``rte_flow_item_*`` structures implemented to have protocol
> struct, target is convert all to this usage.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>

> ---
> Cc: Thomas Monjalon <thomas@monjalon.net>
> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Cc: Ori Kam <orika@nvidia.com>
>
> v2:
> * Defer actual cleanup to the v21.11 LTS release
> ---
>  doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 96986fabd598..90b6fbc9548c 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -88,6 +88,16 @@ Deprecation Notices
>    will be limited to maximum 256 queues.
>    Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
>
> +* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
> +  should start with relevant protocol header.
> +  Some matching pattern structures implements this by duplicating protocol header
> +  fields in the struct. To clarify the intention and to be sure protocol header
> +  is intact, will replace those fields with relevant protocol header struct.
> +  In v21.02 both individual protocol header fields and the protocol header struct
> +  will be added as union, target is switch usage to the protocol header by time.
> +  In v21.11 LTS, protocol header fields will be cleaned and only protocol header
> +  struct will remain.
> +
>  * sched: To allow more traffic classes, flexible mapping of pipe queues to
>    traffic classes, and subport level configuration of pipes and queues
>    changes will be made to macros, data structures and API functions defined
> --
> 2.26.2
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH v2] doc: announce flow API matching pattern struct changes
  2020-11-24 13:15 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
  2020-11-24 14:29   ` Ajit Khaparde
@ 2020-11-27 16:16   ` Bruce Richardson
  1 sibling, 0 replies; 13+ messages in thread
From: Bruce Richardson @ 2020-11-27 16:16 UTC (permalink / raw)
  To: Ferruh Yigit
  Cc: Ray Kinsella, Neil Horman, dev, Andrew Rybchenko,
	Thomas Monjalon, Ori Kam

On Tue, Nov 24, 2020 at 01:15:35PM +0000, Ferruh Yigit wrote:
> Proposing to replace protocol header fields in the ``rte_flow_item_*``
> structures with the protocol structs.
> 
> This is both for documenting the intention and to be sure
> ``rte_flow_item_*`` always starts with complete protocol header.
> 
> Change will be done in two steps, at first step in v21.02 release,
> protocol header struct will be added as union, for example:
> 
> Current ``struct rte_flow_item_eth``,
> 
> struct rte_flow_item_eth {
> 	struct rte_ether_addr dst;
> 	struct rte_ether_addr src;
> 	rte_be16_t type;
> 	uint32_t has_vlan:1;
> 	uint32_t reserved:31;
> }
> 
> will become in v21.02:
> 
> __extension__
> struct rte_flow_item_eth {
> 	union {
> 		struct {
> 			struct rte_ether_addr dst;
> 			struct rte_ether_addr src;
> 			rte_be16_t type;
> 		};
> 		struct rte_ether_hdr hdr;
> 	};
> 	uint32_t has_vlan:1;
> 	uint32_t reserved:31;
> }
> 
> After this point usage should switch to 'hdr' struct.
> 
> And in the second step, in the v21.11 LTS release the protocol fields
> will be removed, and the struct will become:
> 
> struct rte_flow_item_eth {
> 	struct rte_ether_hdr hdr;
> 	uint32_t has_vlan:1;
> 	uint32_t reserved:31;
> }
> 
> Already many ``rte_flow_item_*`` structures implemented to have protocol
> struct, target is convert all to this usage.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> ---
> Cc: Thomas Monjalon <thomas@monjalon.net>
> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Cc: Ori Kam <orika@nvidia.com>
> 
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [dpdk-dev] [PATCH v2] doc: announce flow API matching pattern struct changes
  2020-11-24 14:29   ` Ajit Khaparde
@ 2020-11-27 17:56     ` Thomas Monjalon
  0 siblings, 0 replies; 13+ messages in thread
From: Thomas Monjalon @ 2020-11-27 17:56 UTC (permalink / raw)
  To: Ferruh Yigit
  Cc: dev, Ray Kinsella, Neil Horman, Andrew Rybchenko, Ori Kam,
	Ajit Khaparde, bruce.richardson

24/11/2020 15:29, Ajit Khaparde:
> On Tue, Nov 24, 2020 at 5:15 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> > Proposing to replace protocol header fields in the ``rte_flow_item_*``
> > structures with the protocol structs.
> >
> > This is both for documenting the intention and to be sure
> > ``rte_flow_item_*`` always starts with complete protocol header.
> >
> > Change will be done in two steps, at first step in v21.02 release,
> > protocol header struct will be added as union, for example:
> >
> > Current ``struct rte_flow_item_eth``,
> >
> > struct rte_flow_item_eth {
> >         struct rte_ether_addr dst;
> >         struct rte_ether_addr src;
> >         rte_be16_t type;
> >         uint32_t has_vlan:1;
> >         uint32_t reserved:31;
> > }
> >
> > will become in v21.02:
> >
> > __extension__
> > struct rte_flow_item_eth {
> >         union {
> >                 struct {
> >                         struct rte_ether_addr dst;
> >                         struct rte_ether_addr src;
> >                         rte_be16_t type;
> >                 };
> >                 struct rte_ether_hdr hdr;
> >         };
> >         uint32_t has_vlan:1;
> >         uint32_t reserved:31;
> > }
> >
> > After this point usage should switch to 'hdr' struct.
> >
> > And in the second step, in the v21.11 LTS release the protocol fields
> > will be removed, and the struct will become:
> >
> > struct rte_flow_item_eth {
> >         struct rte_ether_hdr hdr;
> >         uint32_t has_vlan:1;
> >         uint32_t reserved:31;
> > }
> >
> > Already many ``rte_flow_item_*`` structures implemented to have protocol
> > struct, target is convert all to this usage.
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>

Acked-by: Thomas Monjalon <thomas@monjalon.net>

Applied, thanks



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-11-27 17:56 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-23 13:40 [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes Ferruh Yigit
2020-11-23 13:50 ` Andrew Rybchenko
2020-11-23 14:17   ` Ferruh Yigit
2020-11-23 14:25     ` Andrew Rybchenko
2020-11-23 15:51       ` Ferruh Yigit
2020-11-24 11:43         ` Ori Kam
2020-11-24 12:56           ` Ferruh Yigit
2020-11-24 13:00             ` Andrew Rybchenko
2020-11-24 13:01               ` Andrew Rybchenko
2020-11-24 13:15 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2020-11-24 14:29   ` Ajit Khaparde
2020-11-27 17:56     ` Thomas Monjalon
2020-11-27 16:16   ` Bruce Richardson

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git