From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Ori Kam" <orika@nvidia.com>,
"Jerin Jacob" <jerinjacobk@gmail.com>
Cc: "NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
<david.marchand@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
<jerinj@marvell.com>, <ferruh.yigit@amd.com>,
<techboard@dpdk.org>, "Mcnamara, John" <john.mcnamara@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>, <dev@dpdk.org>
Subject: RE: [PATCH] ethdev: introduce generic flow item and action
Date: Wed, 16 Aug 2023 16:20:46 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87B0B@smartserver.smartshare.dk> (raw)
In-Reply-To: <DS0PR11MB7442FA5FD7E623E164D700CDEB15A@DS0PR11MB7442.namprd11.prod.outlook.com>
> From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com]
> Sent: Wednesday, 16 August 2023 15.23
>
> Hi Morten,
>
> <snip>
>
> > > >
> > > > In order to avoid conflicts between P4 and non-P4 generic flow
> > > items/actions,
> > > > the generic type should include information about how to interpret the
> > > > information, which is why I suggest making it a Vendor-Specific type,
> with
> > > > vendor-specific TLV's (managed by the vendor), like the RADIUS Vendor-
> > > > Specific attributes I compared to, instead of just an opaque blob.
> > >
> > > I like this idea, but it is not necessary to introduce a vendor-specific
> type,
> > > it could be considered a device-specific type (or port-specific in the
> context
> > > of DPDK).
> > >
> > > However, the PMD can manage a dictionary, enabling users to query about
> > the
> > > format of each generic item or action if we can expose a set of query
> APIs.
> > >
> > > But I guess we don't need vendor-id / vendor-type as RADIUS does, as we
> > have
> > > port_id here.
> >
> > If the flow item itself doesn't have a "type" field (identifying how to
> interpret
> > the blob), you might have two different NICs using each their own blob
> > format. The NIC must be able to determine if a given flow item is of a type
> it
> > can understand, before it tries to parse the blob in it.
> >
> > This is why the "struct rte_flow_item" has a "type" field. It tells the HW
> how
> > to interpret the values in a flow item.
> >
> > If we introduce a "generic" flow item type, it can only be used for multiple
> > purposes (i.e. both P4, but also other purposes than P4) if it has a "sub-
> type"
> > field. Otherwise, someone will create a "generic" flow item containing a P4
> > program and send it to a NIC, which uses the "generic" flow item type for
> > other program types, e.g. a cBPF program. And this cBPF capable NIC has no
> > way to detect that the blob in the flow item is not a cBPF program, but a P4
> > program. The P4 capable NIC will accept the P4 program, but will be confused
> > when sent the cBPF program understood by the first NIC.
> >
> > So I am suggesting that the "generic" flow items and actions follow an
> existing
> > and well known design patterns for how to identify the meaning of blobs:
> > Include a Vendor-ID followed by vendor-specific TLV formatted data.
> >
> > As I wrote initially, I am opposed to introducing uninterpretable blobs into
> > DPDK. Flow items/actions need to be well defined. Allowing "Vendor-Specific"
> > flow items/actions is a workaround that allows you to bypass the normal
> > standardization process.
> >
>
> I would be happy to add mechanisms to describe the user-defined flow items
> and actions in greater detail. Would you be able to provide some examples for
> your proposal for a flow item and a flow action of your choice, please?
> Thanks!
>
> One thing I would want to stress here: the flow items and flow actions are
> defined exclusively by the user (through their P4 program) without any
> knowledge or intervention from the HW vendor, so any TLVs / helper fields
> must be populated by the user as opposed to the HW vendor.
Perhaps I have completely misunderstood this patch...
I thought the purpose is for the user to define some generic flow items and actions, which are not in the list of DPDK standardized (and fully documented) RTE_FLOW items/actions, but are understood by a variety of programmable NICs from various HW vendors. In this case, each blob needs to be prefixed with a "type" field, so the HW can determine which of its processing engines needs to parse the blob. E.g. a NIC could have both a P4 processing engine and a BPF processing engine, so the blob needs to indicate which of the two engines to use for the provided flow item/action.
But maybe the purpose is completely different. Is the purpose of this patch to introduce flow items and flow actions, which each make the HW perform a "callback" to the user application? In this case, only the user application (handling the "callbacks") can understand them, and thus they are completely opaque to everything else.
>
> <snip>
>
> Regards,
> Cristian
next prev parent reply other threads:[~2023-08-16 14:20 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 17:34 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 [this message]
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
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=98CBD80474FA8B44BF855DF32C47DC35D87B0B@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--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=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).