DPDK usage discussions
 help / color / mirror / Atom feed
From: Tom Barbette <tom.barbette@uclouvain.be>
To: Daniel Romell <dromell@sandvine.com>, "users@dpdk.org" <users@dpdk.org>
Cc: "orika@nvidia.com" <orika@nvidia.com>,
	"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
	"barbette@kth.se" <barbette@kth.se>
Subject: Re: rte_flow MARK + JUMP with mlx5
Date: Fri, 12 Nov 2021 10:34:17 +0100	[thread overview]
Message-ID: <b681e72a-2bf0-dd98-5a09-ed4415eaf288@uclouvain.be> (raw)
In-Reply-To: <a0168092b9214d2fb11bc0d791d834d2@sandvine.com>

[-- Attachment #1: Type: text/plain, Size: 3663 bytes --]

Le 11-11-21 à 13:48, Daniel Romell a écrit :
> 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 expected to survive to the target flow group? Is it driver 
> specific? Undefined? 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 marked:
>
> 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 of the traffic, and another set of rules that would mark a small 
> subset of the traffic before being processed by the RSS rule.
>
> I realize I *could* duplicate the RSS actions and have them in the 
> same rule as the MARK, but that just seems like the wrong thing to do 
> for a few different 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 RSS rules should be long-lived and static.
> * The code inserting the MARK rule ideally shouldn't have be aware of 
> the RSS config (other than that it should continue to a new group for 
> further matching).


As far as I know, and from that discussion you mention, there is no "go 
back to the default global RSS action" action. Once you add a rule, 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 
> driver, 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 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 similar setup through the 
> rte_flow API?
>
> 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 
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fusers%40dpdk.org%2Fmsg03900.html&data=04%7C01%7Ctom.barbette%40uclouvain.be%7C467455655f1c4a1527ef08d9a51199f5%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637722317846203685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Nkx%2F26braD4JuxxbcmLdpO7IB1yFQ53%2Bjd4%2BaiX1Nn4%3D&reserved=0>)
>
> *Disclaimer:*
> This communication (including any attachments) is intended for the use 
> of the intended recipient(s) only and may contain information that is 
> considered confidential, proprietary, sensitive and/or otherwise 
> legally protected. Any unauthorized use or dissemination of this 
> communication is strictly prohibited. If you have received this 
> communication 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.
>

[-- Attachment #2: Type: text/html, Size: 6614 bytes --]

  reply	other threads:[~2021-11-12  9:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 12:48 Daniel Romell
2021-11-12  9:34 ` Tom Barbette [this message]
2021-11-16  8:24   ` Daniel Romell
2022-01-28 10:54 ` Daniel Romell
2022-02-15 16:03   ` Daniel Romell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b681e72a-2bf0-dd98-5a09-ed4415eaf288@uclouvain.be \
    --to=tom.barbette@uclouvain.be \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=barbette@kth.se \
    --cc=dromell@sandvine.com \
    --cc=orika@nvidia.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).