On 20/11/2019 18: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-e40320100...@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. >
Yes, 18.11.5 was released on Friday evening, not planning any more 18.11 releases for at least 2 months (famous last words). >> >>>> 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. >>> >> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev