From: Thomas Monjalon <thomas@monjalon.net>
To: Ori Kam <orika@mellanox.com>,
David Marchand <david.marchand@redhat.com>,
Andrew Rybchenko <arybchenko@solarflare.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] doc: update RSS action with best effort
Date: Mon, 03 Aug 2020 18:12:27 +0200 [thread overview]
Message-ID: <5309847.jfmgeefGoo@thomas> (raw)
In-Reply-To: <5b902c08-69b3-905b-3b95-2ce12e94a63b@solarflare.com>
03/08/2020 17:55, Andrew Rybchenko:
> On 8/3/20 6:49 PM, Ori Kam wrote:
> > From: David Marchand <david.marchand@redhat.com>
> >> On Mon, Aug 3, 2020 at 5:23 PM Ori Kam <orika@mellanox.com> wrote:
> >>>>> +
> >>>>> +- Hashing on types that are not supported by the PMD.
> >>>> Shouldn't it return error to the caller?
> >>>>
> >>> That’s depends, if for example the application requested eth and IPv4,
> >>> and the PMD can do only IPv4 so according to this, the PMD will just do IPv4.
> >> We should have some validation in ethdev to catch this.
> >> Is it not the case?
> >>
> > Like I said in my reply to Andrew, in rte_flow we don't have such caps.
> > Maybe we should think about adding them for the RSS case, but again it is tricky
> > What if one RSS type is supported depending on the flow or other types?
>
> Also I'd like to add that ethdev layer is dummy for rte_flow API.
> It does not parse pattern/actions etc. May be should change it one day.
For now, what we can do is to have "best effort" (sic) checks.
In the case we are 100% sure a rule cannot be fully supported,
I think we should reject the rule.
If there are more complex cases to handle, we can accept the rule
and support it with "best effort" handling.
The other appropriate action is to implement tests in DTS
to check the behaviour of the PMDs, validating the compliance
of the accepted rules with real flows.
next prev parent reply other threads:[~2020-08-03 16:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 14:28 Ori Kam
2020-08-03 14:33 ` Andrew Rybchenko
2020-08-03 15:22 ` Ori Kam
2020-08-03 15:33 ` Andrew Rybchenko
2020-08-03 15:47 ` Ori Kam
2020-08-03 16:03 ` Andrew Rybchenko
2020-08-03 16:53 ` Ori Kam
2020-08-03 15:40 ` David Marchand
2020-08-03 15:49 ` Ori Kam
2020-08-03 15:55 ` Andrew Rybchenko
2020-08-03 16:12 ` Thomas Monjalon [this message]
2020-09-14 14:29 ` Ferruh Yigit
2020-08-04 8:13 ` [dpdk-dev] [PATCH v2] " Ori Kam
2020-08-05 12:39 ` Ori Kam
2020-08-05 13:39 ` Andrew Rybchenko
2020-08-05 14:08 ` Ori Kam
2020-08-06 12:14 ` Andrew Rybchenko
2020-08-06 16:55 ` Ori Kam
2020-09-14 14:38 ` Ferruh Yigit
2020-08-07 5:02 ` [dpdk-dev] [PATCH v3] " Ori Kam
2020-08-07 9:41 ` Andrew Rybchenko
2020-08-10 7:40 ` Ori Kam
2020-08-10 9:53 ` Andrew Rybchenko
2020-08-10 15:08 ` [dpdk-dev] [PATCH v4] " Ori Kam
2020-09-14 14:43 ` Ferruh Yigit
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=5309847.jfmgeefGoo@thomas \
--to=thomas@monjalon.net \
--cc=arybchenko@solarflare.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=orika@mellanox.com \
/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).