[1/2] ethdev: introduce transfer attribute to shared action conf
Checks
Commit Message
In a flow rule, attribute "transfer" means operation level
at which both traffic is matched and actions are conducted.
Add the very same attribute to shared action configuration.
If a driver needs to prepare HW resources in two different
ways, depending on the operation level, in order to set up
an action, then this new attribute will indicate the level.
Also, when handling a flow rule insertion, the driver will
be able to turn down a shared action if its level is unfit.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
---
lib/librte_ethdev/rte_flow.h | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On 10/29/2020 11:46 AM, Ivan Malov wrote:
> In a flow rule, attribute "transfer" means operation level
> at which both traffic is matched and actions are conducted.
>
> Add the very same attribute to shared action configuration.
> If a driver needs to prepare HW resources in two different
> ways, depending on the operation level, in order to set up
> an action, then this new attribute will indicate the level.
> Also, when handling a flow rule insertion, the driver will
> be able to turn down a shared action if its level is unfit.
>
> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Hi Ivan,
Is this for 21.02?
On 10/29/20 3:37 PM, Ferruh Yigit wrote:
> On 10/29/2020 11:46 AM, Ivan Malov wrote:
>> In a flow rule, attribute "transfer" means operation level
>> at which both traffic is matched and actions are conducted.
>>
>> Add the very same attribute to shared action configuration.
>> If a driver needs to prepare HW resources in two different
>> ways, depending on the operation level, in order to set up
>> an action, then this new attribute will indicate the level.
>> Also, when handling a flow rule insertion, the driver will
>> be able to turn down a shared action if its level is unfit.
>>
>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>
> Hi Ivan,
>
> Is this for 21.02?
Since the feature is new and experimental, we'd prefer
to see in 20.11 (could be considered as a fix?), but
I realize that it is late and past API freeze.
I'd let net/mlx5 maintainers to decide as the only
driver which supports shared actions now.
Hi Ivan,
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ivan Malov
> Sent: Thursday, October 29, 2020 7:47 PM
> To: dev@dpdk.org
> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Subject: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> shared action conf
>
> In a flow rule, attribute "transfer" means operation level at which both traffic
> is matched and actions are conducted.
>
> Add the very same attribute to shared action configuration.
> If a driver needs to prepare HW resources in two different ways, depending
> on the operation level, in order to set up an action, then this new attribute
> will indicate the level.
> Also, when handling a flow rule insertion, the driver will be able to turn
> down a shared action if its level is unfit.
Most actions apply to both level, rss and queue action applies on non-transfer level,
Port action applies to transfer level. Is there a particular scenario for this new attribute?
>
> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> ---
> lib/librte_ethdev/rte_flow.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index
> a8eac4deb..0b993d8eb 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -3487,6 +3487,13 @@ struct rte_flow_shared_action_conf {
> /**< Action valid for rules applied to ingress traffic. */
> uint32_t egress:1;
> /**< Action valid for rules applied to egress traffic. */
> +
> + /**
> + * This attribute matches that of the flow rules which
> + * are supposed to comprise the given shared action.
> + * See struct rte_flow_attr.
> + */
> + uint32_t transfer:1;
> };
>
> /**
> --
> 2.20.1
Hi,
On 30/10/2020 18:49, Xueming(Steven) Li wrote:
> Hi Ivan,
>
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Ivan Malov
>> Sent: Thursday, October 29, 2020 7:47 PM
>> To: dev@dpdk.org
>> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
>> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew
>> Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Subject: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
>> shared action conf
>>
>> In a flow rule, attribute "transfer" means operation level at which both traffic
>> is matched and actions are conducted.
>>
>> Add the very same attribute to shared action configuration.
>> If a driver needs to prepare HW resources in two different ways, depending
>> on the operation level, in order to set up an action, then this new attribute
>> will indicate the level.
>> Also, when handling a flow rule insertion, the driver will be able to turn
>> down a shared action if its level is unfit.
> Most actions apply to both level, rss and queue action applies on non-transfer level,
> Port action applies to transfer level. Is there a particular scenario for this new attribute?
Most doesn't mean all, and you've already described some of the
exceptions. And that's exactly the deal. Particular scenarios are don't
cares given the fact that such an attribute is meant to be a generic
solution. If an action happens to be supported on both levels, this
doesn't necessarily mean that HW resources/objects that need to be
prepared in the two cases are of the same type (or programmed to the NIC
the same way). This is exactly what applies to flow rules (which do have
attribute transfer) and what should be done to shared action conf, too.
If this still seems vague, please let me know.
>
>>
>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>> ---
>> lib/librte_ethdev/rte_flow.h | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index
>> a8eac4deb..0b993d8eb 100644
>> --- a/lib/librte_ethdev/rte_flow.h
>> +++ b/lib/librte_ethdev/rte_flow.h
>> @@ -3487,6 +3487,13 @@ struct rte_flow_shared_action_conf {
>> /**< Action valid for rules applied to ingress traffic. */
>> uint32_t egress:1;
>> /**< Action valid for rules applied to egress traffic. */
>> +
>> + /**
>> + * This attribute matches that of the flow rules which
>> + * are supposed to comprise the given shared action.
>> + * See struct rte_flow_attr.
>> + */
>> + uint32_t transfer:1;
>> };
>>
>> /**
>> --
>> 2.20.1
Hi Ivan,
> -----Original Message-----
> From: Ivan Malov <Ivan.Malov@oktetlabs.ru>
> Sent: Friday, October 30, 2020 10:35 PM
> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> shared action conf
>
> Hi,
>
> On 30/10/2020 18:49, Xueming(Steven) Li wrote:
> > Hi Ivan,
> >
> >> -----Original Message-----
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Ivan Malov
> >> Sent: Thursday, October 29, 2020 7:47 PM
> >> To: dev@dpdk.org
> >> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> >> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew
> >> Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >> Subject: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> >> shared action conf
> >>
> >> In a flow rule, attribute "transfer" means operation level at which both
> traffic
> >> is matched and actions are conducted.
> >>
> >> Add the very same attribute to shared action configuration.
> >> If a driver needs to prepare HW resources in two different ways, depending
> >> on the operation level, in order to set up an action, then this new attribute
> >> will indicate the level.
> >> Also, when handling a flow rule insertion, the driver will be able to turn
> >> down a shared action if its level is unfit.
> > Most actions apply to both level, rss and queue action applies on non-transfer
> level,
> > Port action applies to transfer level. Is there a particular scenario for this new
> attribute?
>
> Most doesn't mean all, and you've already described some of the
> exceptions. And that's exactly the deal. Particular scenarios are don't
> cares given the fact that such an attribute is meant to be a generic
> solution. If an action happens to be supported on both levels, this
> doesn't necessarily mean that HW resources/objects that need to be
> prepared in the two cases are of the same type (or programmed to the NIC
> the same way). This is exactly what applies to flow rules (which do have
> attribute transfer) and what should be done to shared action conf, too.
>
> If this still seems vague, please let me know.
>
The only question is can we see a reason to share action between transfer and
non transfer?
I don't see such a reason and I think it can improve the code. So I vote to add it.
In any case, you are missing the rte_flow rst update.
I can see that the rst also misses the ingress bits, can you please also
create a fix for those?
Thanks,
Ori
> >
> >>
> >> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> >> ---
> >> lib/librte_ethdev/rte_flow.h | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index
> >> a8eac4deb..0b993d8eb 100644
> >> --- a/lib/librte_ethdev/rte_flow.h
> >> +++ b/lib/librte_ethdev/rte_flow.h
> >> @@ -3487,6 +3487,13 @@ struct rte_flow_shared_action_conf {
> >> /**< Action valid for rules applied to ingress traffic. */
> >> uint32_t egress:1;
> >> /**< Action valid for rules applied to egress traffic. */
> >> +
> >> + /**
> >> + * This attribute matches that of the flow rules which
> >> + * are supposed to comprise the given shared action.
> >> + * See struct rte_flow_attr.
> >> + */
> >> + uint32_t transfer:1;
> >> };
> >>
> >> /**
> >> --
> >> 2.20.1
>
> --
> Ivan M
Hi Ivan
> -----Original Message-----
> From: Ori Kam
> Sent: Sunday, November 1, 2020 10:12 AM
> Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> shared action conf
>
> Hi Ivan,
>
> > -----Original Message-----
> > From: Ivan Malov <Ivan.Malov@oktetlabs.ru>
> > Sent: Friday, October 30, 2020 10:35 PM
> > Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> > shared action conf
> >
> > Hi,
> >
> > On 30/10/2020 18:49, Xueming(Steven) Li wrote:
> > > Hi Ivan,
> > >
> > >> -----Original Message-----
> > >> From: dev <dev-bounces@dpdk.org> On Behalf Of Ivan Malov
> > >> Sent: Thursday, October 29, 2020 7:47 PM
> > >> To: dev@dpdk.org
> > >> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > >> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew
> > >> Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > >> Subject: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> > >> shared action conf
> > >>
> > >> In a flow rule, attribute "transfer" means operation level at which both
> > traffic
> > >> is matched and actions are conducted.
> > >>
> > >> Add the very same attribute to shared action configuration.
> > >> If a driver needs to prepare HW resources in two different ways,
> depending
> > >> on the operation level, in order to set up an action, then this new attribute
> > >> will indicate the level.
> > >> Also, when handling a flow rule insertion, the driver will be able to turn
> > >> down a shared action if its level is unfit.
> > > Most actions apply to both level, rss and queue action applies on non-
> transfer
> > level,
> > > Port action applies to transfer level. Is there a particular scenario for this
> new
> > attribute?
> >
> > Most doesn't mean all, and you've already described some of the
> > exceptions. And that's exactly the deal. Particular scenarios are don't
> > cares given the fact that such an attribute is meant to be a generic
> > solution. If an action happens to be supported on both levels, this
> > doesn't necessarily mean that HW resources/objects that need to be
> > prepared in the two cases are of the same type (or programmed to the NIC
> > the same way). This is exactly what applies to flow rules (which do have
> > attribute transfer) and what should be done to shared action conf, too.
> >
> > If this still seems vague, please let me know.
> >
>
> The only question is can we see a reason to share action between transfer and
> non transfer?
>
> I don't see such a reason and I think it can improve the code. So I vote to add it.
>
>
> In any case, you are missing the rte_flow rst update.
> I can see that the rst also misses the ingress bits, can you please also
> create a fix for those?
>
Please disregard my last comment about doc update.
Ori
> Thanks,
> Ori
>
>
> > >
> > >>
> > >> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> > >> ---
> > >> lib/librte_ethdev/rte_flow.h | 7 +++++++
> > >> 1 file changed, 7 insertions(+)
> > >>
> > >> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index
> > >> a8eac4deb..0b993d8eb 100644
> > >> --- a/lib/librte_ethdev/rte_flow.h
> > >> +++ b/lib/librte_ethdev/rte_flow.h
> > >> @@ -3487,6 +3487,13 @@ struct rte_flow_shared_action_conf {
> > >> /**< Action valid for rules applied to ingress traffic. */
> > >> uint32_t egress:1;
> > >> /**< Action valid for rules applied to egress traffic. */
> > >> +
> > >> + /**
> > >> + * This attribute matches that of the flow rules which
> > >> + * are supposed to comprise the given shared action.
> > >> + * See struct rte_flow_attr.
> > >> + */
> > >> + uint32_t transfer:1;
> > >> };
> > >>
> > >> /**
> > >> --
> > >> 2.20.1
> >
> > --
> > Ivan M
Hi Ivan,
PSB small comment about the comment,
And feel free to add my ack.
Best,
Ori
> -----Original Message-----
> From: Ori Kam
> Sent: Sunday, November 1, 2020 11:35 AM
> Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> shared action conf
>
> Hi Ivan
>
> > -----Original Message-----
> > From: Ori Kam
> > Sent: Sunday, November 1, 2020 10:12 AM
> > Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> > shared action conf
> >
> > Hi Ivan,
> >
> > > -----Original Message-----
> > > From: Ivan Malov <Ivan.Malov@oktetlabs.ru>
> > > Sent: Friday, October 30, 2020 10:35 PM
> > > Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> > > shared action conf
> > >
> > > Hi,
> > >
> > > On 30/10/2020 18:49, Xueming(Steven) Li wrote:
> > > > Hi Ivan,
> > > >
> > > >> -----Original Message-----
> > > >> From: dev <dev-bounces@dpdk.org> On Behalf Of Ivan Malov
> > > >> Sent: Thursday, October 29, 2020 7:47 PM
> > > >> To: dev@dpdk.org
> > > >> Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > > >> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew
> > > >> Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > > >> Subject: [dpdk-dev] [PATCH 1/2] ethdev: introduce transfer attribute to
> > > >> shared action conf
> > > >>
> > > >> In a flow rule, attribute "transfer" means operation level at which both
> > > traffic
> > > >> is matched and actions are conducted.
> > > >>
> > > >> Add the very same attribute to shared action configuration.
> > > >> If a driver needs to prepare HW resources in two different ways,
> > depending
> > > >> on the operation level, in order to set up an action, then this new
> attribute
> > > >> will indicate the level.
> > > >> Also, when handling a flow rule insertion, the driver will be able to turn
> > > >> down a shared action if its level is unfit.
> > > > Most actions apply to both level, rss and queue action applies on non-
> > transfer
> > > level,
> > > > Port action applies to transfer level. Is there a particular scenario for this
> > new
> > > attribute?
> > >
> > > Most doesn't mean all, and you've already described some of the
> > > exceptions. And that's exactly the deal. Particular scenarios are don't
> > > cares given the fact that such an attribute is meant to be a generic
> > > solution. If an action happens to be supported on both levels, this
> > > doesn't necessarily mean that HW resources/objects that need to be
> > > prepared in the two cases are of the same type (or programmed to the NIC
> > > the same way). This is exactly what applies to flow rules (which do have
> > > attribute transfer) and what should be done to shared action conf, too.
> > >
> > > If this still seems vague, please let me know.
> > >
> >
> > The only question is can we see a reason to share action between transfer
> and
> > non transfer?
> >
> > I don't see such a reason and I think it can improve the code. So I vote to add
> it.
> >
> >
> > In any case, you are missing the rte_flow rst update.
> > I can see that the rst also misses the ingress bits, can you please also
> > create a fix for those?
> >
> Please disregard my last comment about doc update.
>
> Ori
>
> > Thanks,
> > Ori
> >
> >
> > > >
> > > >>
> > > >> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> > > >> ---
> > > >> lib/librte_ethdev/rte_flow.h | 7 +++++++
> > > >> 1 file changed, 7 insertions(+)
> > > >>
> > > >> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index
> > > >> a8eac4deb..0b993d8eb 100644
> > > >> --- a/lib/librte_ethdev/rte_flow.h
> > > >> +++ b/lib/librte_ethdev/rte_flow.h
> > > >> @@ -3487,6 +3487,13 @@ struct rte_flow_shared_action_conf {
> > > >> /**< Action valid for rules applied to ingress traffic. */
> > > >> uint32_t egress:1;
> > > >> /**< Action valid for rules applied to egress traffic. */
> > > >> +
> > > >> + /**
> > > >> + * This attribute matches that of the flow rules which
> > > >> + * are supposed to comprise the given shared action.
> > > >> + * See struct rte_flow_attr.
> > > >> + */
Can you please rephrase the comment, to something like
"Action valid for transfer traffic."
> > > >> + uint32_t transfer:1;
> > > >> };
> > > >>
> > > >> /**
> > > >> --
> > > >> 2.20.1
> > >
> > > --
> > > Ivan M
@@ -3487,6 +3487,13 @@ struct rte_flow_shared_action_conf {
/**< Action valid for rules applied to ingress traffic. */
uint32_t egress:1;
/**< Action valid for rules applied to egress traffic. */
+
+ /**
+ * This attribute matches that of the flow rules which
+ * are supposed to comprise the given shared action.
+ * See struct rte_flow_attr.
+ */
+ uint32_t transfer:1;
};
/**