Re: [ovs-discuss] include/sparse/rte_flow.h
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-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.
>
>>
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.
Re: [ovs-discuss] include/sparse/rte_flow.h
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.
>>>
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] include/sparse/rte_flow.h
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.
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.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] include/sparse/rte_flow.h
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.
>> 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.
>
> Best regards, Ilya Maximets.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] include/sparse/rte_flow.h
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?
>
> 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.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] include/sparse/rte_flow.h
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
2. submit directly on dpdk-latest
>
> 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?
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?
>
> Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] include/sparse/rte_flow.h
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.
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.
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?
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] include/sparse/rte_flow.h
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? > > > Please advise, > > Thanks, > > Eli > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
