From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3DFA7A0C43 for ; Tue, 16 Nov 2021 09:24:20 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1211741157; Tue, 16 Nov 2021 09:24:14 +0100 (CET) Received: from mail1.sandvine.com (mail1.sandvine.com [207.219.248.234]) by mails.dpdk.org (Postfix) with ESMTP id 24D3141149 for ; Tue, 16 Nov 2021 09:24:13 +0100 (CET) Received: from WTL-EXCHSV2-2.sandvine.com (192.168.194.59) by WTL-EXCHSV2-1.sandvine.com (192.168.194.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2375.17; Tue, 16 Nov 2021 03:22:45 -0500 Received: from WTL-EXCHSV2-2.sandvine.com ([fe80::2498:2176:180e:c4b0]) by WTL-EXCHSV2-2.sandvine.com ([fe80::2498:2176:180e:c4b0%20]) with mapi id 15.01.2375.017; Tue, 16 Nov 2021 03:24:11 -0500 From: Daniel Romell To: Tom Barbette , "users@dpdk.org" CC: "orika@nvidia.com" , "andrew.rybchenko@oktetlabs.ru" , "barbette@kth.se" Subject: Re: rte_flow MARK + JUMP with mlx5 Thread-Topic: rte_flow MARK + JUMP with mlx5 Thread-Index: AQHX1vhEPyg3NAnhck6mVeWQH9pUzqv/9s2AgAXhrpA= Date: Tue, 16 Nov 2021 08:24:10 +0000 Message-ID: <6cfb8874773c4c52961701e686b1306b@sandvine.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.34.119] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_6cfb8874773c4c52961701e686b1306bsandvinecom_" MIME-Version: 1.0 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --_000_6cfb8874773c4c52961701e686b1306bsandvinecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Tom! I think the shared/handle interface could help a bit in reducing duplicatio= n, but I guess the flow rules where I end up using the handle would still h= ave to match whatever RSS action is configured in the handle, so I'm not su= re it actually abstracts anything away in the case of RSS. It would also still be interesting to hear if anyone has any input on eithe= r the JUMP + MARK question, or if there's another way to get to the simple = 2-flow-table-setup i mentioned in the first question. / Daniel ________________________________ From: Tom Barbette Sent: Friday, November 12, 2021 10:34:17 AM To: Daniel Romell; users@dpdk.org Cc: orika@nvidia.com; andrew.rybchenko@oktetlabs.ru; barbette@kth.se Subject: Re: rte_flow MARK + JUMP with mlx5 CAUTION: This email originated from OUTSIDE of the organization. Do NOT cli= ck links or open attachments unless you recognize the sender and know the c= ontent is safe. Le 11-11-21 =E0 13:48, Daniel Romell a =E9crit : Hey all! A few questions about rte_flow, specifically the MARK + JUMP actions; What's the expected behavior of MARK + JUMP in the same flow? Is the mark e= xpected to survive to the target flow group? Is it driver specific? Undefin= ed? Unsupported? For example, when testing with the following flow setup in testpmd (mlx CX6= , DPDK 19.11.2 and latest mainline), none of the received packets are marke= d: flow create 0 ingress pattern eth / end actions mark id 0x1337 / jump group= 1 / end flow create 0 ingress group 1 pattern eth / end actions queue index 0 / end A single flow with MARK + QUEUE works as expected. I don't know about that, I would have expected it to work. What I want in the end is a set of simple RSS rules that would match most o= f the traffic, and another set of rules that would mark a small subset of t= he traffic before being processed by the RSS rule. I realize I *could* duplicate the RSS actions and have them in the same rul= e as the MARK, but that just seems like the wrong thing to do for a few dif= ferent reasons; * It would require one flow for each combination of MARK and RSS condition. * The MARK rules should be inserted and removed during runtime, while the R= SS rules should be long-lived and static. * The code inserting the MARK rule ideally shouldn't have be aware of the R= SS config (other than that it should continue to a new group for further ma= tching). As far as I know, and from that discussion you mention, there is no "go bac= k to the default global RSS action" action. Once you add a rule, you have t= o add the RSS fate action. You can duplicate the "global" RSS using rte_eth_dev_rss_hash_conf_get only= once with the new "shared action" API ( rte_flow_action_handle_create = etc) precisely to avoid creating many RSS context as you mentioned. Tom What's the right way of doing something like this with DPDK? I've already implemented the same thing with a custom/proprietary mlx drive= r, so I know it should be doable. What I ended up doing there was simply to= have two flow tables. The root table (level 0) holds all "mark" rules (flo= w tag), and forwards to everything (including misses) to the next table. Th= e table at level 1 contains the RSS rules, and leaves all flows untagged so= the tag set in the first level is preserved. Is there a way to get to a si= milar setup through the rte_flow API? Thanks, Daniel Romell (CCs as suggested by Thomas in slack + Tom as this seems somewhat similar t= o https://www.mail-archive.com/users@dpdk.org/msg03900.html) Disclaimer: This communication (including any attachments) is intended for the use of t= he intended recipient(s) only and may contain information that is considere= d confidential, proprietary, sensitive and/or otherwise legally protected. = Any unauthorized use or dissemination of this communication is strictly pro= hibited. If you have received this communication in error, please immediate= ly notify the sender by return e-mail message and delete all copies of the = original communication. Thank you for your cooperation. --_000_6cfb8874773c4c52961701e686b1306bsandvinecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Tom!

I think the shared/handle interface could help a bit in reducing duplicatio= n, but I guess the flow rules where I end up using the handle would still h= ave to match whatever RSS action is configured in the handle, so I'm not su= re it actually abstracts anything away in the case of RSS.

It would also still be interesting to hear if anyone has any input on eithe= r the JUMP + MARK question, or if there's another way to get to the sim= ple 2-flow-table-setup i mentioned in the first question.

/ Daniel

From: Tom Barbette <tom.= barbette@uclouvain.be>
Sent: Friday, November 12, 2021 10:34:17 AM
To: Daniel Romell; users@dpdk.org
Cc: orika@nvidia.com; andrew.rybchenko@oktetlabs.ru; barbette@kth.se=
Subject: Re: rte_flow MARK + JUMP with mlx5
 
CAUTION: This email= originated from OUTSIDE of the organization. Do NOT click links or open attachments unless you recognize the sender = and know the content is safe.

Le 11-11-21 =E0 13:48, Daniel Romell a =E9crit :
Hey all!

A few questions about rte_flow, specifically the MARK + JUMP actions;
What's the expected behavior of MARK + JUMP in the same flow? Is the ma= rk expected to survive to the target flow group? Is it driver specific? Und= efined? Unsupported?

For example, when testing with the following flow setup in testpmd (mlx CX6= , DPDK 19.11.2 and latest mainline), none of the received packets are marke= d:

flow create 0 ingress pattern eth / end actions mark id 0x1337 / jump group= 1 / end
flow create 0 ingress group 1 pattern eth / end actions queue index 0 / end=

A single flow with MARK + QUEUE works as expected.
I don't know about that, I would have expected it to work.

What I want in the end is a set of simple RSS rules that would match most o= f the traffic, and another set of rules that would mark a small subset of t= he traffic before being processed by the RSS rule.

I realize I *could* duplicate the RSS actions and have them in the same rul= e as the MARK, but that just seems like the wrong thing to do for a few dif= ferent reasons;
* It would require one flow for each combination of MARK and RSS condition.=
* The MARK rules should be inserted and removed during runtime, while the R= SS rules should be long-lived and static.
* The code inserting the MARK rule ideally shouldn't have be aware of the R= SS config (other than that it should continue to a new group for further ma= tching).


As far as I know, and from that discussion you mention, there is no &quo= t;go back to the default global RSS action" action. Once you add a rul= e, you have to add the RSS fate action.


You can duplicate the "global" RSS using rte_eth_dev_rss_hash_= conf_get only once with the new "shared action" API  ( =    rte_flow_action_handle_create etc) precisely to avoid creating= many RSS context as you mentioned.


Tom


What's the right way of doing something like this with DPDK?
I've already implemented the same thing with a custom/proprietary mlx drive= r, so I know it should be doable. What I ended up doing there was simply to= have two flow tables. The root table (level 0) holds all "mark" = rules (flow tag), and forwards to everything (including misses) to the next table. The table at level 1 contains the RS= S rules, and leaves all flows untagged so the tag set in the first level is= preserved. Is there a way to get to a similar setup through the rte_flow A= PI?

Thanks,
Daniel Romell

(CCs as suggested by Thomas in slack + Tom as this seems somewhat = similar to https://www.mail-archive.com/users@dpdk.org/msg03900.html)

Disclaimer:
This communication (including any attachments) is intended for the use of t= he intended recipient(s) only and may contain information that is considere= d confidential, proprietary, sensitive and/or otherwise legally protected. = Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this co= mmunication in error, please immediately notify the sender by return e-mail= message and delete all copies of the original communication. Thank you for= your cooperation.

--_000_6cfb8874773c4c52961701e686b1306bsandvinecom_--