From: Stephen Hemminger <stephen@networkplumber.org>
To: Ori Kam <orika@nvidia.com>
Cc: "Ferruh Yigit" <ferruh.yigit@amd.com>,
"Jerin Jacob" <jerinjacobk@gmail.com>,
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
"Morten Brørup" <mb@smartsharesystems.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
"David Marchand" <david.marchand@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Jerin Jacob" <jerinj@marvell.com>,
techboard@dpdk.org, "Mcnamara, John" <john.mcnamara@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>, dev <dev@dpdk.org>
Subject: Re: DPDK community: RTE_FLOW support for P4-programmable devices
Date: Thu, 31 Aug 2023 15:42:51 +0200 [thread overview]
Message-ID: <CAOaVG14myW7_z9Jp5WHBUicDamEjfzj=iSFYrbjjan_OSGVtaA@mail.gmail.com> (raw)
In-Reply-To: <MW2PR12MB4666CFFEA9FD09C453D409AED6E5A@MW2PR12MB4666.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]
It also introduces lots of new test conditions. For example, can a P4 flow
be deleted, supersed, or read by a flow created by rte_flow.
On Thu, Aug 31, 2023, 12:32 PM Ori Kam <orika@nvidia.com> wrote:
> Hi
>
> > -----Original Message-----
> > From: Ferruh Yigit <ferruh.yigit@amd.com>
> > Sent: Tuesday, August 29, 2023 1:18 PM
> > devices
> >
> > On 8/29/2023 8:38 AM, Jerin Jacob wrote:
> > > On Mon, Aug 28, 2023 at 9:43 PM Dumitrescu, Cristian
> > > <cristian.dumitrescu@intel.com> wrote:
> > >>
> > >>>> We just set up a community call for next week to discuss in more
> details
> > the
> > >>>> proposal for RTE_FLOW extensions to support P4-programmable devices
> > >>>> https://mails.dpdk.org/archives/dev/2023-August/273703.html and
> look
> > for
> > >>>> ways to converge and make progress.
> > >>>>
> > >>>> All the people from To: and CC: are already invited. To avoid
> cluttering
> > >>> people's
> > >>>> calendars, I did not add dev@dpdk.org, so if anybody else wants to
> attend,
> > >>>> please send me a private email and I will be happy to forward the
> invite.
> > >>>>
> > >>>> Thanks,
> > >>>> Cristian
> > >>
> > >> Attendees: Morten Brorup, Jerin Jacob, Anoob Joseph, Vipin Varghese,
> Qi
> > Zhang,
> > >> Cristian Dumitrescu
> > >>
> > >> 1. Ori (RTE_FLOW maintainer) and others were not present, probably on
> > vacation,
> > >> hopefully they will be able to attend the next call on this topic.
> Ferruh had a
> > last
> > >> minute conflict that he could not avoid.
> > >>
> > >> 2. Cristian presented a few slides (attached) with the problem
> statement,
> > current
> > >> RTE_FLOW gaps for P4-programmable devices and the list of current
> > solution
> > >> proposals.
> > >>
> > >> 3. Everybody on the call agreed that the P4-programmable devices from
> > Intel,
> > >> AMD and others need to be fully supported by DPDK and that there are
> > some
> > >> gaps in RTE_FLOW to be fixed for supporting these devices.
> > >
> > > Personally, It makes sense to me to have normative DPDK API to send p4
> > > runtime message to the
> > > ethdev so that we have "vendor neutral + DPDK based" p4 runtime
> backend.
> > >
> > > I prefer to have specialized ethdev ops for this due to the following
> reasons.
> > >
> > > # If the ethdev has both real TCAM based HW(for existing rte_flow
> > > patterns and actions) and SW agent to receive P4 runtime message etc.
> > > Typically, it needs to take a different path in driver to talk.
> Assume, if you
> > > have cascaded patterns/actions, One is targeted for TCAM and other for
> > > SW agent for p4, one
> > > need to have serious amount checking for dispatching.It complicates
> > > the driver and forbid to have
> > > driver optimization especially cases for templates etc. if user making
> > > rules for both category of HW.
> > >
> >
> > Indeed I am not against dedicated APIs for P4 runtime backend.
> >
> > But assuming there is a dedicated rte_flow item for P4, how it is
> > different than dedicated API in above scenario?
> > If driver detects P4 runtime specific rule, it can bail it out to SW
> agent.
> > Can you please elaborate the complexity it introduces?
> >
> > > # All we need "char buffer//string" based communication ethdev <-> app.
> > >
> >
> > Yes, and both a dedicated API or dedicated rte_flow item can provide
> > medium for this communication.
> >
> > rte_flow one has flexibility & extensibility advantages, but maybe not
> > as straightforward as an API.
>
> I think not using the rte_flow will also require duplication of all the
> rule handling functions and table creations, for example aync rule
> create/destroy query ......
>
>
[-- Attachment #2: Type: text/html, Size: 5054 bytes --]
next prev parent reply other threads:[~2023-08-31 13:43 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 17:34 [PATCH] ethdev: introduce generic flow item and action Qi Zhang
2023-08-02 9:37 ` Zhang, Qi Z
2023-08-02 10:25 ` Morten Brørup
2023-08-02 11:01 ` Morten Brørup
2023-08-02 11:21 ` Jerin Jacob
2023-08-02 14:06 ` Dumitrescu, Cristian
2023-08-02 15:24 ` Morten Brørup
2023-08-02 15:47 ` Ori Kam
2023-08-02 16:06 ` Ori Kam
2023-08-02 17:22 ` Dumitrescu, Cristian
2023-08-02 17:56 ` Morten Brørup
2023-08-03 1:05 ` Zhang, Qi Z
2023-08-03 13:57 ` Morten Brørup
2023-08-16 13:23 ` Dumitrescu, Cristian
2023-08-16 14:20 ` Morten Brørup
2023-08-16 17:08 ` Ferruh Yigit
2023-08-16 17:18 ` Dumitrescu, Cristian
2023-08-16 16:19 ` DPDK community: RTE_FLOW support for P4-programmable devices Dumitrescu, Cristian
2023-08-27 7:48 ` Ori Kam
2023-08-28 16:12 ` Dumitrescu, Cristian
2023-08-29 7:38 ` Jerin Jacob
2023-08-29 10:18 ` Ferruh Yigit
2023-08-31 10:32 ` Ori Kam
2023-08-31 13:42 ` Stephen Hemminger [this message]
2023-09-01 2:07 ` Jerin Jacob
2023-09-01 6:57 ` Ori Kam
2023-09-01 9:52 ` Jerin Jacob
2023-09-04 7:45 ` Ferruh Yigit
2023-09-06 8:30 ` Ori Kam
2023-09-11 20:20 ` Dumitrescu, Cristian
2023-08-02 16:56 ` [PATCH] ethdev: introduce generic flow item and action Dumitrescu, Cristian
2023-08-03 8:39 ` Ori Kam
2023-08-16 13:12 ` Dumitrescu, Cristian
2023-08-02 16:14 ` Dumitrescu, Cristian
2023-08-02 14:06 ` Dumitrescu, Cristian
2023-08-02 14:54 ` Morten Brørup
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='CAOaVG14myW7_z9Jp5WHBUicDamEjfzj=iSFYrbjjan_OSGVtaA@mail.gmail.com' \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=helin.zhang@intel.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=john.mcnamara@intel.com \
--cc=mb@smartsharesystems.com \
--cc=orika@nvidia.com \
--cc=qi.z.zhang@intel.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/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).