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/[email protected]/
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.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
