DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Ori Kam <orika@nvidia.com>, Jerin Jacob <jerinjacobk@gmail.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>
Cc: "NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
	"Mcnamara, John" <john.mcnamara@intel.com>,
	"Zhang, Helin" <helin.zhang@intel.com>,
	"techboard@dpdk.org" <techboard@dpdk.org>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Ivan Malov <ivan.malov@arknetworks.am>
Subject: RE: [RFC] lib/ethdev: introduce table driven APIs
Date: Wed, 19 Jul 2023 13:39:13 +0000	[thread overview]
Message-ID: <DS0PR11MB74426627935C3001D80B0107EB39A@DS0PR11MB7442.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MW2PR12MB46662EBE06125CBC68F7070DD65CA@MW2PR12MB4666.namprd12.prod.outlook.com>

Hi folks,

> -----Original Message-----
> From: Ori Kam <orika@nvidia.com>
> Sent: Tuesday, June 20, 2023 12:11 PM
> To: Jerin Jacob <jerinjacobk@gmail.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; 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;
> Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> <ivan.malov@arknetworks.am>
> Subject: RE: [RFC] lib/ethdev: introduce table driven APIs
> 
<snip>

> >
> > Yes. We need to change the backend compiler to understand the rte_flow
> > mapping to p4 to avoid any translation cost.
> +1
> I think the idea is that the complier will convert to rte_flow and supply some
> mapping file so when application uses some name it will be translated to the
> correct
> preconfigured rte_flow action

Sorry to join late to this thread.

Let me try to clarify the role of the P4 compiler:

1. P4 compiler is for the data path only, while this proposal is for a control path API.

2. The P4 program simply defines the data path pipeline, i.e. the table topology that
Ivan was mentioning. The P4 compiler takes this P4 program as input and translates
it to a sort of firmware that the HW understands and loads to create that data path.

3. The P4 program defines the key and action formats for each table, but it does NOT
contain the set of entries (key/action pairs) for each table; the actual table entries are
populated post-init by the user using a control path API such as RTE_FLOW or other.

So what Qi's proposal is about is a control path API to populate the tables, an API that
is similar to the RTE_FLOW API, and not about a data path API to define a topology of
tables (the table topology is either hardcoded at HW design time or configured in HW at
init time by "firmware" produced by the P4 compiler out of a P4 program).

Makes sense?

Regards,
Cristian

  reply	other threads:[~2023-07-19 13:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 11:15 Qi Zhang
2023-06-12 15:32 ` Ivan Malov
2023-06-13  3:48   ` Zhang, Qi Z
2023-06-13  6:38     ` Ivan Malov
2023-06-14  5:42       ` Zhang, Qi Z
2023-06-14 18:30 ` Ori Kam
2023-06-15  2:25   ` Zhang, Qi Z
2023-06-15  4:57     ` Jerin Jacob
2023-06-15  6:03       ` Zhang, Qi Z
2023-06-15  6:21         ` Jerin Jacob
2023-06-15  7:42           ` Zhang, Qi Z
2023-06-15  8:37             ` Jerin Jacob
2023-06-15 13:25               ` Zhang, Qi Z
2023-06-16  1:20                 ` Jerin Jacob
2023-06-19  0:22                   ` Zhang, Qi Z
2023-06-19  9:52                     ` Jerin Jacob
2023-06-20  1:52                       ` Zhang, Qi Z
2023-06-20  5:06                         ` Jerin Jacob
2023-06-20 11:10                           ` Ori Kam
2023-07-19 13:39                             ` Dumitrescu, Cristian [this message]
2023-08-02  9:31                               ` Dumitrescu, Cristian

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=DS0PR11MB74426627935C3001D80B0107EB39A@DS0PR11MB7442.namprd11.prod.outlook.com \
    --to=cristian.dumitrescu@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=helin.zhang@intel.com \
    --cc=ivan.malov@arknetworks.am \
    --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).