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.yi...@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.yi...@intel.com>
>>>>>>>
>>>>>>> Acked-by: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
>>>>>>>
>>>>>>> a minor note below
>>>>>>>
>>>>>>>> ---
>>>>>>>> Cc: Thomas Monjalon <tho...@monjalon.net>
>>>>>>>> Cc: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
>>>>>>>> Cc: Ori Kam <or...@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
