All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ajit Khaparde <ajit.khaparde@broadcom.com>
To: Ori Kam <orika@nvidia.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Martin Havlik <xhavli56@stud.fit.vutbr.cz>,
	 NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	 Ferruh Yigit <ferruh.yigit@intel.com>,
	Dekel Peled <dekelp@nvidia.com>, Bing Zhao <bingz@nvidia.com>,
	 Gregory Etelson <getelson@nvidia.com>,
	Eli Britstein <elibr@nvidia.com>,
	 Alexander Kozyrev <akozyrev@nvidia.com>, dpdk-dev <dev@dpdk.org>,
	Jan Viktorin <viktorin@cesnet.cz>
Subject: Re: [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour
Date: Mon, 26 Jul 2021 07:52:29 -0700	[thread overview]
Message-ID: <CACZ4nhs33Mmc4Lop6zRV72JTdd6wUvhgCfazcsKAvOt7cX3JmA@mail.gmail.com> (raw)
In-Reply-To: <DM8PR12MB5400562ADF94758F479522F4D6E89@DM8PR12MB5400.namprd12.prod.outlook.com>

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

On Sun, Jul 25, 2021 at 11:46 PM Ori Kam <orika@nvidia.com> wrote:
>
> Hi
>
> > -----Original Message-----
> > From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> > Sent: Monday, July 26, 2021 6:07 AM
> >
> > On Wed, Jul 21, 2021 at 11:16 AM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > On Wed, 21 Jul 2021 17:58:14 +0200
> > > Martin Havlik <xhavli56@stud.fit.vutbr.cz> wrote:
> > >
> > > > The ability to create RTE flow rules, depending on
> > > > port status, can and does differ between PMDs.
> > > > Now the doc reflects that.
> > > >
> > > > Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> > > > ---
> > > >  doc/guides/prog_guide/rte_flow.rst | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > > > index 2b42d5ec8c..2988e3328a 100644
> > > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > > @@ -3097,6 +3097,10 @@ actually created and a handle returned.
> > > >                     const struct rte_flow_action *actions[],
> > > >                     struct rte_flow_error *error);
> > > >
> > > > +The ability to create a flow rule may depend on the status
> > (started/stopped)
> > > > +of the port for which the rule is being created. This behaviour is
> > > > +PMD specific. Seek relevant PMD documentation for details.
> > >
> > > Any PMD specific behavior in DPDK is an anathema to application
> > developers
> > > and should be considered a design flaw!
> > But it is better to be clear about the behavior.
> > Drivers and their underlying devices may need certain resources to be
> > initialized before flows could be created. There may be some drivers
> > who do not need that.
> > Specifying ports to be started would cover both the cases.
> >
> > Maybe then we can say that "some drivers may _not_ need the port to be
> > started. Check PMD specific documentation".
>
> I don't like the negative approach, if a driver doesn't have any issues with something
> it doesn't need to say it support this, the driver may say if it wants to emphasize
> but this shouldn't be the default.
> I prefer the original suggestion, maybe we can add device cap for this, just like
> if a the PMD allows modifying queues after start.
+1.
Device cap should help tie this behavior.

>
> Best
> Ori
>

      reply	other threads:[~2021-07-26 14:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 15:58 [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour Martin Havlik
2021-07-21 15:58 ` [dpdk-dev] [PATCH 3/4] doc: update bonding mode 8023ad info Martin Havlik
2021-07-26  1:39   ` Min Hu (Connor)
2021-07-21 18:16 ` [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour Stephen Hemminger
2021-07-22 10:33   ` Andrew Rybchenko
2021-07-26  3:07   ` Ajit Khaparde
2021-07-26  6:46     ` Ori Kam
2021-07-26 14:52       ` Ajit Khaparde [this message]

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=CACZ4nhs33Mmc4Lop6zRV72JTdd6wUvhgCfazcsKAvOt7cX3JmA@mail.gmail.com \
    --to=ajit.khaparde@broadcom.com \
    --cc=akozyrev@nvidia.com \
    --cc=arybchenko@solarflare.com \
    --cc=bingz@nvidia.com \
    --cc=dekelp@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=elibr@nvidia.com \
    --cc=ferruh.yigit@intel.com \
    --cc=getelson@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=viktorin@cesnet.cz \
    --cc=xhavli56@stud.fit.vutbr.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.