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(+) 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
This attribute helps PMDs to tell actions supposed to work on the so-called hardware e-switch level from regular ones. Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru> --- app/test-pmd/cmdline_flow.c | 12 ++++++++++++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index 3d1dd0595..a0f63c684 100644 --- a/app/test-pmd/cmdline_flow.c +++ b/app/test-pmd/cmdline_flow.c @@ -114,6 +114,7 @@ enum index { SHARED_ACTION_CREATE_ID, SHARED_ACTION_INGRESS, SHARED_ACTION_EGRESS, + SHARED_ACTION_TRANSFER, SHARED_ACTION_SPEC, /* Shared action destroy arguments */ @@ -782,6 +783,7 @@ static const enum index next_sa_create_attr[] = { SHARED_ACTION_CREATE_ID, SHARED_ACTION_INGRESS, SHARED_ACTION_EGRESS, + SHARED_ACTION_TRANSFER, SHARED_ACTION_SPEC, ZERO, }; @@ -4280,6 +4282,12 @@ static const struct token token_list[] = { .next = NEXT(next_sa_create_attr), .call = parse_sa, }, + [SHARED_ACTION_TRANSFER] = { + .name = "transfer", + .help = "affect rule to transfer", + .next = NEXT(next_sa_create_attr), + .call = parse_sa, + }, [SHARED_ACTION_SPEC] = { .name = "action", .help = "specify action to share", @@ -4515,6 +4523,9 @@ parse_sa(struct context *ctx, const struct token *token, case SHARED_ACTION_INGRESS: out->args.vc.attr.ingress = 1; return len; + case SHARED_ACTION_TRANSFER: + out->args.vc.attr.transfer = 1; + return len; default: return -1; } @@ -7267,6 +7278,7 @@ cmd_flow_parsed(const struct buffer *in) &((const struct rte_flow_shared_action_conf) { .ingress = in->args.vc.attr.ingress, .egress = in->args.vc.attr.egress, + .transfer = in->args.vc.attr.transfer, }), in->args.vc.actions); break; diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 70d20113e..da6e407e8 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -4782,7 +4782,7 @@ Creating shared actions shared action ID. It is bound to ``rte_flow_shared_action_create()``:: flow shared_action {port_id} create [action_id {shared_action_id}] - [ingress] [egress] action {action} / end + [ingress] [egress] [transfer] action {action} / end If successful, it will show:: -- 2.20.1
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 -- Ivan M
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
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> Acked-by: Ori Kam <orika@nvidia.com> --- ...-transfer-attribute-to-shared-action.patch | 42 ++++++++++ ...ort-shared-flow-action-attribute-tra.patch | 82 +++++++++++++++++++ lib/librte_ethdev/rte_flow.h | 8 ++ 3 files changed, 132 insertions(+) create mode 100644 0001-ethdev-introduce-transfer-attribute-to-shared-action.patch create mode 100644 0002-app-testpmd-support-shared-flow-action-attribute-tra.patch diff --git a/0001-ethdev-introduce-transfer-attribute-to-shared-action.patch b/0001-ethdev-introduce-transfer-attribute-to-shared-action.patch new file mode 100644 index 000000000..b0bf9063e --- /dev/null +++ b/0001-ethdev-introduce-transfer-attribute-to-shared-action.patch @@ -0,0 +1,42 @@ +From 802259bb546259663f979fb7695b8a9fd15bed31 Mon Sep 17 00:00:00 2001 +From: Ivan Malov <ivan.malov@oktetlabs.ru> +Date: Thu, 29 Oct 2020 06:54:46 +0300 +Subject: [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. + +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 + diff --git a/0002-app-testpmd-support-shared-flow-action-attribute-tra.patch b/0002-app-testpmd-support-shared-flow-action-attribute-tra.patch new file mode 100644 index 000000000..d503d5d45 --- /dev/null +++ b/0002-app-testpmd-support-shared-flow-action-attribute-tra.patch @@ -0,0 +1,82 @@ +From 9732bc93169af1040731a4a66bd6ef44a878576b Mon Sep 17 00:00:00 2001 +From: Ivan Malov <ivan.malov@oktetlabs.ru> +Date: Thu, 29 Oct 2020 12:42:11 +0300 +Subject: [PATCH 2/2] app/testpmd: support shared flow action attribute + transfer + +This attribute helps PMDs to tell actions supposed to work +on the so-called hardware e-switch level from regular ones. + +Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru> +--- + app/test-pmd/cmdline_flow.c | 12 ++++++++++++ + doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +- + 2 files changed, 13 insertions(+), 1 deletion(-) + +diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c +index c68d22fda..fe18cca27 100644 +--- a/app/test-pmd/cmdline_flow.c ++++ b/app/test-pmd/cmdline_flow.c +@@ -114,6 +114,7 @@ enum index { + SHARED_ACTION_CREATE_ID, + SHARED_ACTION_INGRESS, + SHARED_ACTION_EGRESS, ++ SHARED_ACTION_TRANSFER, + SHARED_ACTION_SPEC, + + /* Shared action destroy arguments */ +@@ -782,6 +783,7 @@ static const enum index next_sa_create_attr[] = { + SHARED_ACTION_CREATE_ID, + SHARED_ACTION_INGRESS, + SHARED_ACTION_EGRESS, ++ SHARED_ACTION_TRANSFER, + SHARED_ACTION_SPEC, + ZERO, + }; +@@ -4286,6 +4288,12 @@ static const struct token token_list[] = { + .next = NEXT(next_sa_create_attr), + .call = parse_sa, + }, ++ [SHARED_ACTION_TRANSFER] = { ++ .name = "transfer", ++ .help = "affect rule to transfer", ++ .next = NEXT(next_sa_create_attr), ++ .call = parse_sa, ++ }, + [SHARED_ACTION_SPEC] = { + .name = "action", + .help = "specify action to share", +@@ -4521,6 +4529,9 @@ parse_sa(struct context *ctx, const struct token *token, + case SHARED_ACTION_INGRESS: + out->args.vc.attr.ingress = 1; + return len; ++ case SHARED_ACTION_TRANSFER: ++ out->args.vc.attr.transfer = 1; ++ return len; + default: + return -1; + } +@@ -7273,6 +7284,7 @@ cmd_flow_parsed(const struct buffer *in) + &((const struct rte_flow_shared_action_conf) { + .ingress = in->args.vc.attr.ingress, + .egress = in->args.vc.attr.egress, ++ .transfer = in->args.vc.attr.transfer, + }), + in->args.vc.actions); + break; +diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst +index 289df193b..ebf7e68f8 100644 +--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst ++++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst +@@ -4318,7 +4318,7 @@ Creating shared actions + shared action ID. It is bound to ``rte_flow_shared_action_create()``:: + + flow shared_action {port_id} create [action_id {shared_action_id}] +- [ingress] [egress] action {action} / end ++ [ingress] [egress] [transfer] action {action} / end + + If successful, it will show:: + +-- +2.20.1 + diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index a8eac4deb..8b970ba0b 100644 --- a/lib/librte_ethdev/rte_flow.h +++ b/lib/librte_ethdev/rte_flow.h @@ -3487,6 +3487,14 @@ 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. */ + + /** + * When set to 1, indicates that the action is valid for + * transfer traffic; otherwise, for non-transfer traffic. + * + * See struct rte_flow_attr. + */ + uint32_t transfer:1; }; /** -- 2.20.1
This attribute helps PMDs to tell actions supposed to work on the so-called hardware e-switch level from regular ones. Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru> --- app/test-pmd/cmdline_flow.c | 12 ++++++++++++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index c68d22fda..fe18cca27 100644 --- a/app/test-pmd/cmdline_flow.c +++ b/app/test-pmd/cmdline_flow.c @@ -114,6 +114,7 @@ enum index { SHARED_ACTION_CREATE_ID, SHARED_ACTION_INGRESS, SHARED_ACTION_EGRESS, + SHARED_ACTION_TRANSFER, SHARED_ACTION_SPEC, /* Shared action destroy arguments */ @@ -782,6 +783,7 @@ static const enum index next_sa_create_attr[] = { SHARED_ACTION_CREATE_ID, SHARED_ACTION_INGRESS, SHARED_ACTION_EGRESS, + SHARED_ACTION_TRANSFER, SHARED_ACTION_SPEC, ZERO, }; @@ -4286,6 +4288,12 @@ static const struct token token_list[] = { .next = NEXT(next_sa_create_attr), .call = parse_sa, }, + [SHARED_ACTION_TRANSFER] = { + .name = "transfer", + .help = "affect rule to transfer", + .next = NEXT(next_sa_create_attr), + .call = parse_sa, + }, [SHARED_ACTION_SPEC] = { .name = "action", .help = "specify action to share", @@ -4521,6 +4529,9 @@ parse_sa(struct context *ctx, const struct token *token, case SHARED_ACTION_INGRESS: out->args.vc.attr.ingress = 1; return len; + case SHARED_ACTION_TRANSFER: + out->args.vc.attr.transfer = 1; + return len; default: return -1; } @@ -7273,6 +7284,7 @@ cmd_flow_parsed(const struct buffer *in) &((const struct rte_flow_shared_action_conf) { .ingress = in->args.vc.attr.ingress, .egress = in->args.vc.attr.egress, + .transfer = in->args.vc.attr.transfer, }), in->args.vc.actions); break; diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 289df193b..ebf7e68f8 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -4318,7 +4318,7 @@ Creating shared actions shared action ID. It is bound to ``rte_flow_shared_action_create()``:: flow shared_action {port_id} create [action_id {shared_action_id}] - [ingress] [egress] action {action} / end + [ingress] [egress] [transfer] action {action} / end If successful, it will show:: -- 2.20.1
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> Acked-by: Ori Kam <orika@nvidia.com> --- lib/librte_ethdev/rte_flow.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index a8eac4deb..8b970ba0b 100644 --- a/lib/librte_ethdev/rte_flow.h +++ b/lib/librte_ethdev/rte_flow.h @@ -3487,6 +3487,14 @@ 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. */ + + /** + * When set to 1, indicates that the action is valid for + * transfer traffic; otherwise, for non-transfer traffic. + * + * See struct rte_flow_attr. + */ + uint32_t transfer:1; }; /** -- 2.20.1
This attribute helps PMDs to tell actions supposed to work on the so-called hardware e-switch level from regular ones. Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru> --- app/test-pmd/cmdline_flow.c | 12 ++++++++++++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index c68d22fda..fe18cca27 100644 --- a/app/test-pmd/cmdline_flow.c +++ b/app/test-pmd/cmdline_flow.c @@ -114,6 +114,7 @@ enum index { SHARED_ACTION_CREATE_ID, SHARED_ACTION_INGRESS, SHARED_ACTION_EGRESS, + SHARED_ACTION_TRANSFER, SHARED_ACTION_SPEC, /* Shared action destroy arguments */ @@ -782,6 +783,7 @@ static const enum index next_sa_create_attr[] = { SHARED_ACTION_CREATE_ID, SHARED_ACTION_INGRESS, SHARED_ACTION_EGRESS, + SHARED_ACTION_TRANSFER, SHARED_ACTION_SPEC, ZERO, }; @@ -4286,6 +4288,12 @@ static const struct token token_list[] = { .next = NEXT(next_sa_create_attr), .call = parse_sa, }, + [SHARED_ACTION_TRANSFER] = { + .name = "transfer", + .help = "affect rule to transfer", + .next = NEXT(next_sa_create_attr), + .call = parse_sa, + }, [SHARED_ACTION_SPEC] = { .name = "action", .help = "specify action to share", @@ -4521,6 +4529,9 @@ parse_sa(struct context *ctx, const struct token *token, case SHARED_ACTION_INGRESS: out->args.vc.attr.ingress = 1; return len; + case SHARED_ACTION_TRANSFER: + out->args.vc.attr.transfer = 1; + return len; default: return -1; } @@ -7273,6 +7284,7 @@ cmd_flow_parsed(const struct buffer *in) &((const struct rte_flow_shared_action_conf) { .ingress = in->args.vc.attr.ingress, .egress = in->args.vc.attr.egress, + .transfer = in->args.vc.attr.transfer, }), in->args.vc.actions); break; diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 289df193b..ebf7e68f8 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -4318,7 +4318,7 @@ Creating shared actions shared action ID. It is bound to ``rte_flow_shared_action_create()``:: flow shared_action {port_id} create [action_id {shared_action_id}] - [ingress] [egress] action {action} / end + [ingress] [egress] [transfer] action {action} / end If successful, it will show:: -- 2.20.1
On 11/2/20 2:43 PM, 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>
> Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@oktetlabs.ru>
> Sent: Monday, November 2, 2020 1:43 PM
> To: dev@dpdk.org
> Cc: Xueming(Steven) Li <xuemingl@nvidia.com>; Ori Kam <orika@nvidia.com>;
> Wenzhuo Lu <wenzhuo.lu@intel.com>; Beilei Xing <beilei.xing@intel.com>;
> Bernard Iremonger <bernard.iremonger@intel.com>
> Subject: [PATCH v3 2/2] app/testpmd: support shared flow action attribute
> transfer
>
> This attribute helps PMDs to tell actions supposed to work
> on the so-called hardware e-switch level from regular ones.
>
> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> ---
> app/test-pmd/cmdline_flow.c | 12 ++++++++++++
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index c68d22fda..fe18cca27 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -114,6 +114,7 @@ enum index {
> SHARED_ACTION_CREATE_ID,
> SHARED_ACTION_INGRESS,
> SHARED_ACTION_EGRESS,
> + SHARED_ACTION_TRANSFER,
> SHARED_ACTION_SPEC,
>
> /* Shared action destroy arguments */
> @@ -782,6 +783,7 @@ static const enum index next_sa_create_attr[] = {
> SHARED_ACTION_CREATE_ID,
> SHARED_ACTION_INGRESS,
> SHARED_ACTION_EGRESS,
> + SHARED_ACTION_TRANSFER,
> SHARED_ACTION_SPEC,
> ZERO,
> };
> @@ -4286,6 +4288,12 @@ static const struct token token_list[] = {
> .next = NEXT(next_sa_create_attr),
> .call = parse_sa,
> },
> + [SHARED_ACTION_TRANSFER] = {
> + .name = "transfer",
> + .help = "affect rule to transfer",
> + .next = NEXT(next_sa_create_attr),
> + .call = parse_sa,
> + },
> [SHARED_ACTION_SPEC] = {
> .name = "action",
> .help = "specify action to share",
> @@ -4521,6 +4529,9 @@ parse_sa(struct context *ctx, const struct token
> *token,
> case SHARED_ACTION_INGRESS:
> out->args.vc.attr.ingress = 1;
> return len;
> + case SHARED_ACTION_TRANSFER:
> + out->args.vc.attr.transfer = 1;
> + return len;
> default:
> return -1;
> }
> @@ -7273,6 +7284,7 @@ cmd_flow_parsed(const struct buffer *in)
> &((const struct rte_flow_shared_action_conf) {
> .ingress = in->args.vc.attr.ingress,
> .egress = in->args.vc.attr.egress,
> + .transfer = in->args.vc.attr.transfer,
> }),
> in->args.vc.actions);
> break;
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 289df193b..ebf7e68f8 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -4318,7 +4318,7 @@ Creating shared actions
> shared action ID. It is bound to ``rte_flow_shared_action_create()``::
>
> flow shared_action {port_id} create [action_id {shared_action_id}]
> - [ingress] [egress] action {action} / end
> + [ingress] [egress] [transfer] action {action} / end
>
> If successful, it will show::
>
> --
> 2.20.1
Acked-by: Ori Kam <orika@nvidia.com>
Thanks,
Ori
On 11/2/2020 11:43 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>
> Acked-by: Ori Kam <orika@nvidia.com>
> ---
> lib/librte_ethdev/rte_flow.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index a8eac4deb..8b970ba0b 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -3487,6 +3487,14 @@ 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. */
> +
> + /**
> + * When set to 1, indicates that the action is valid for
> + * transfer traffic; otherwise, for non-transfer traffic.
> + *
> + * See struct rte_flow_attr.
> + */
> + uint32_t transfer:1;
Is this require any documentation update?
Also cc'ed Andrey, as he is author of the shared action feature, @Andrey can you
please review this update?
On Mon, Nov 2, 2020 at 5:15 AM Andrew Rybchenko <
andrew.rybchenko@oktetlabs.ru> wrote:
> On 11/2/20 2:43 PM, 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>
> > Acked-by: Ori Kam <orika@nvidia.com>
>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Hi Ferruh,
On 02/11/2020 21:54, Ferruh Yigit wrote:
> On 11/2/2020 11:43 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>
>> Acked-by: Ori Kam <orika@nvidia.com>
>> ---
>> lib/librte_ethdev/rte_flow.h | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
>> index a8eac4deb..8b970ba0b 100644
>> --- a/lib/librte_ethdev/rte_flow.h
>> +++ b/lib/librte_ethdev/rte_flow.h
>> @@ -3487,6 +3487,14 @@ 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. */
>> +
>> + /**
>> + * When set to 1, indicates that the action is valid for
>> + * transfer traffic; otherwise, for non-transfer traffic.
>> + *
>> + * See struct rte_flow_attr.
>> + */
>> + uint32_t transfer:1;
>
> Is this require any documentation update?
>
> Also cc'ed Andrey, as he is author of the shared action feature, @Andrey
> can you please review this update?
Many-many thanks to you for reviewing the patch. And thanks for inviting
@Andrey. I should've done that from the very beginning.
What's for documentation update, = I did take a look at
"doc/guides/prog_guide/rte_flow.rst" after Ori had suggested to do so.
As far as I can learn from the file, the convention is to describe the
action structure itself, i.e. not any auxiliary structures.
For example, direct input to action SHARED is "struct
rte_flow_shared_action". And it's already described by an empty table
("table:: SHARED") in the doc file.
On the other hand, documentation of "struct rte_flow_shared_action_conf"
belongs in a place where the API rte_flow_shared_action_create() is
documented. This API is only mentioned by
"doc/guides/prog_guide/rte_flow.rst", and it looks like it's not
documented anywhere but in the header file itself
("lib/librte_ethdev/rte_flow.h").
So, it looks like this particular patch does not need to provide an
update to documentation other that the existing comment before the field
in the structure.
--
Ivan M
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Monday, November 2, 2020 8:55 PM
> To: Ivan Malov <ivan.malov@oktetlabs.ru>; dev@dpdk.org; Andrey Vesnovaty
> <andreyv@nvidia.com>
> Cc: Xueming(Steven) Li <xuemingl@nvidia.com>; Ori Kam <orika@nvidia.com>;
> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>
> Subject: Re: [PATCH v3 1/2] ethdev: introduce transfer attribute to shared action
> conf
>
> On 11/2/2020 11:43 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>
> > Acked-by: Ori Kam <orika@nvidia.com>
> > ---
> > lib/librte_ethdev/rte_flow.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index a8eac4deb..8b970ba0b 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -3487,6 +3487,14 @@ 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. */
> > +
> > + /**
> > + * When set to 1, indicates that the action is valid for
> > + * transfer traffic; otherwise, for non-transfer traffic.
> > + *
> > + * See struct rte_flow_attr.
> > + */
> > + uint32_t transfer:1;
>
> Is this require any documentation update?
>
> Also cc'ed Andrey, as he is author of the shared action feature, @Andrey can
> you
> please review this update?
Acked-by: Andrey Vesnovaty <andreyv@nvidia.com>
On 11/3/2020 2:10 PM, Ivan Malov wrote:
> Hi Ferruh,
>
> On 02/11/2020 21:54, Ferruh Yigit wrote:
>> On 11/2/2020 11:43 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>
>>> Acked-by: Ori Kam <orika@nvidia.com>
>>> ---
>>> lib/librte_ethdev/rte_flow.h | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
>>> index a8eac4deb..8b970ba0b 100644
>>> --- a/lib/librte_ethdev/rte_flow.h
>>> +++ b/lib/librte_ethdev/rte_flow.h
>>> @@ -3487,6 +3487,14 @@ 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. */
>>> +
>>> + /**
>>> + * When set to 1, indicates that the action is valid for
>>> + * transfer traffic; otherwise, for non-transfer traffic.
>>> + *
>>> + * See struct rte_flow_attr.
>>> + */
>>> + uint32_t transfer:1;
>>
>> Is this require any documentation update?
>>
>> Also cc'ed Andrey, as he is author of the shared action feature, @Andrey can
>> you please review this update?
>
> Many-many thanks to you for reviewing the patch. And thanks for inviting
> @Andrey. I should've done that from the very beginning.
>
> What's for documentation update, = I did take a look at
> "doc/guides/prog_guide/rte_flow.rst" after Ori had suggested to do so. As far as
> I can learn from the file, the convention is to describe the action structure
> itself, i.e. not any auxiliary structures.
>
> For example, direct input to action SHARED is "struct rte_flow_shared_action".
> And it's already described by an empty table ("table:: SHARED") in the doc file.
>
> On the other hand, documentation of "struct rte_flow_shared_action_conf" belongs
> in a place where the API rte_flow_shared_action_create() is documented. This API
> is only mentioned by "doc/guides/prog_guide/rte_flow.rst", and it looks like
> it's not documented anywhere but in the header file itself
> ("lib/librte_ethdev/rte_flow.h").
>
> So, it looks like this particular patch does not need to provide an update to
> documentation other that the existing comment before the field in the structure.
>
I missed that Ori requested same before, and I agree on your documentation
analysis above, there is not clear location to put this other than doxygen
comment, so OK to proceed as it is.
On 11/3/2020 2:20 PM, Andrey Vesnovaty wrote:
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Monday, November 2, 2020 8:55 PM
>> To: Ivan Malov <ivan.malov@oktetlabs.ru>; dev@dpdk.org; Andrey Vesnovaty
>> <andreyv@nvidia.com>
>> Cc: Xueming(Steven) Li <xuemingl@nvidia.com>; Ori Kam <orika@nvidia.com>;
>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Andrew Rybchenko
>> <andrew.rybchenko@oktetlabs.ru>
>> Subject: Re: [PATCH v3 1/2] ethdev: introduce transfer attribute to shared action
>> conf
>>
>> On 11/2/2020 11:43 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>
>>> Acked-by: Ori Kam <orika@nvidia.com>
>>> ---
>>> lib/librte_ethdev/rte_flow.h | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
>>> index a8eac4deb..8b970ba0b 100644
>>> --- a/lib/librte_ethdev/rte_flow.h
>>> +++ b/lib/librte_ethdev/rte_flow.h
>>> @@ -3487,6 +3487,14 @@ 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. */
>>> +
>>> + /**
>>> + * When set to 1, indicates that the action is valid for
>>> + * transfer traffic; otherwise, for non-transfer traffic.
>>> + *
>>> + * See struct rte_flow_attr.
>>> + */
>>> + uint32_t transfer:1;
>>
>> Is this require any documentation update?
>>
>> Also cc'ed Andrey, as he is author of the shared action feature, @Andrey can
>> you
>> please review this update?
>
> Acked-by: Andrey Vesnovaty <andreyv@nvidia.com>
>
Series applied to dpdk-next-net/main, thanks.