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 --]
next prev parent 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).