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

[Ilya Maximets]

On 20.11.2019 19:14, Stokes, Ian wrote:
> 
> 
> 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?

I don’t know (at least I don’t remember) any specific problem other than
clearing 'ol_flags'.  BTW, The patch is available here:
    https://patchwork.ozlabs.org/patch/1198954/

I'm just a little skeptical, as we have less than 4 weeks (excluding OVS
conf and Christmas / New Year holidays) until a soft freeze and there is
no much activity in a mail-list.

Best regards, Ilya Maximets.