[ovs-dev] include/sparse/rte_flow.h

[Stokes, Ian]

On 11/20/2019 6:02 PM, Kevin Traynor wrote:
> On 19/11/2019 18:48, Ilya Maximets wrote:
>> On 19.11.2019 19:01, Eli Britstein wrote:
>>>
>>> On 11/19/2019 7:46 PM, Ilya Maximets wrote:
>>>> On 19.11.2019 18:29, Eli Britstein wrote:
>>>>> On 11/19/2019 7:27 PM, Eli Britstein wrote:
>>>>>> Hi
>>>>>>
>>>>>> I see this file has many inconsistencies against the one from DPDK
>>>>>> (18.11.2).
>>>>>>
>>>>>> For example, this API:
>>>>>>
>>>>>> rte_flow_query(uint16_t port_id,
>>>>>>              struct rte_flow *flow,
>>>>>>              enum rte_flow_action_type action,
>>>>>>              void *data,
>>>>>>              struct rte_flow_error *error);
>>>>>>
>>>>>> is wrong, vs the one from DPDK:
>>>>>>
>>>>>> rte_flow_query(uint16_t port_id,
>>>>>>              struct rte_flow *flow,
>>>>>>              const struct rte_flow_action *action,
>>>>>>              void *data,
>>>>>>              struct rte_flow_error *error);
>>>>>>
>>>>>> Note the "action" argument.
>>>>>>
>>>>>>
>>>>>> I also see in it this line:
>>>>>>
>>>>>> #error "Use this header only with sparse.  It is not a correct
>>>>>> implementation."
>>>>>>
>>>>>>
>>>>>> So, is it wrong on purpose? If so, why?
>>>>>>
>>>>>> I test my patch-set before I submit using travis, and it fails because
>>>>>> of this wrong file. Can we just take the correct code from DPDK?
>>>>>> Should I maybe take only the parts that cause me to fail?
>>>> Hi.  DPDK headers before 18.11.3 has issues that makes sparse unhappy.
>>>> This header will be removed along with upgrade to 18.11.3 or higher.
>>>> Right now we're not experiencing issues with current version of
>>>> sparse header probably just because we're not using most of the functions.
>>> I see. Thanks.
>>>>
>>>> We're not going to update this header only remove.  You may update it in
>>>> your patches or base your changes on top of dpdk-latest branch where this
>>>> header already removed.
>>>
>>> So, what is the preferred way for submission?
>>>
>>> 1. cherry-pick those commits from dpdk-latest on top of master and my
>>> patches on top of that
>>
>> This doesn't sound like a good option.
>> If sparse header needs only few small changes for your patches to work,
>> you may create a special patch for that.  If not, you may send patches
>> as-is but mention that these patches depends on a DPDK 18.11.3+ and another
>> patch that removes the sparse header.
>>
>>>
>>> 2. submit directly on dpdk-latest
>>
>> Not sure about this option because dpdk-latest is mostly for changes that
>> requires most recent DPDK, but this is not exactly your case.
>>
>>>
>>>>
>>>> I'm not sure when we're going to migrate to 18.11.{3,5}.
>>>> @Ian, @Kevin, is validation still in progress?  Does anyone work on this?
>>>
> 
> Ian ran his automated tests at the time of 18.11.3 and reported results
> here:
> http://inbox.dpdk.org/stable/c243e0b9-bac9-9759-c51e-e40320100cae@intel.com/
> I ran some PVP tests also at that time but they were on rpms with some
> patches, so not as relevant.
> 
> Other general 18.11.3 validation is in that thread or there is a summary
> in the release notes
> http://doc.dpdk.org/guides-18.11/rel_notes/release_18_11.html#id7
> 
> I don't think the changes in 18.11.4/5 will have an impact, but if Ian
> is able to re-run those automated tests again, it might be best.

I was holding off moving to 18.11.3 as there was talk on a .4 (and now 
.5 due to CVE I believe), so from a validation point of view we've held 
off until it was settled. We can run validation on .5 if its the case it 
has all required cve fixes.

> 
>>> Is it a question of "if" or "when"? what is the purpose of migrating to
>>> 18.11.3/5 and not to 19.11 soon?
>>
>> 18.11.3/5 requires validation + small patch for docs/CI.
>> 19.11 requires additional development that didn't started yet
>>        + validation + patch for docs/CI.
>>
>> Plus, 18.11 needs to be upgraded on previous versions of OVS too.
>>
>> With current speed of development and validation I will not be surprised if
>> 19.11 will not be supported in next OVS release.

So I would think that this upgrade would go ahead, with RC3 imminent I 
think 19.11 will settle.

I know there is a few issues such as RSS offload which we're looking to 
patch and we're beginning validation now on existing features along with 
required fixes. Is there a particular issue you are aware of that would 
block the 19.11 upgrade?

Ian

>>
>> Best regards, Ilya Maximets.
>>
>