On Tue, Jun 20, 2023 at 7:22 AM Zhang, Qi Z <qi.z.zh...@intel.com> wrote: > > > > > -----Original Message----- > > From: Jerin Jacob <jerinjac...@gmail.com> > > Sent: Monday, June 19, 2023 5:52 PM > > To: Zhang, Qi Z <qi.z.zh...@intel.com> > > Cc: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; Ori Kam > > <or...@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) > > <tho...@monjalon.net>; david.march...@redhat.com; Richardson, Bruce > > <bruce.richard...@intel.com>; jer...@marvell.com; ferruh.yi...@amd.com; > > Mcnamara, John <john.mcnam...@intel.com>; Zhang, Helin > > <helin.zh...@intel.com>; techbo...@dpdk.org; dev@dpdk.org; Ivan Malov > > <ivan.ma...@arknetworks.am> > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs > > > > On Mon, Jun 19, 2023 at 5:53 AM Zhang, Qi Z <qi.z.zh...@intel.com> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob <jerinjac...@gmail.com> > > > > Sent: Friday, June 16, 2023 9:20 AM > > > > To: Zhang, Qi Z <qi.z.zh...@intel.com>; Dumitrescu, Cristian > > > > <cristian.dumitre...@intel.com> > > > > Cc: Ori Kam <or...@nvidia.com>; NBU-Contact-Thomas Monjalon > > > > (EXTERNAL) <tho...@monjalon.net>; david.march...@redhat.com; > > > > Richardson, Bruce <bruce.richard...@intel.com>; jer...@marvell.com; > > > > ferruh.yi...@amd.com; Mcnamara, John <john.mcnam...@intel.com>; > > > > Zhang, Helin <helin.zh...@intel.com>; techbo...@dpdk.org; > > > > dev@dpdk.org; Ivan Malov <ivan.ma...@arknetworks.am> > > > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs > > > >
> > > > > > > > However, the question arises regarding how to handle vendor-specific data, > > which also can be part of the table / action key and could potentially be > > mapped to either rte_flow_item_tag or rte_flow_item_metadata. I'm > > uncertain about how the P4-DPDK compiler can manage this aspect. Perhaps > > this particular aspect should be addressed by each vendor's individual > > backend compiler, while we focus on defining the specifications for the > > output and providing the common components for parser analysis. > > > > If we take the compiler path, Why we need vendor specific data? > > Let's consider the following scenario: > > Assume that a hardware device contains metadata that can be passed between > different stages of a pipeline. > > For instance, in stage A, a rule is matched, and the metadata is set. In > stage B, this metadata is used as a match key. > > To design the API calls for the above situation using rte_flow, my > understanding is that we need to map a rte_flow_item_tag or > rte_flow_item_metadata to the corresponding metadata portion (including > offset and size). > This way, the driver can understand how to configure the hardware accordingly. > > In P4, we define data structures to abstract the metadata, and the vender > specific-backend compiler determines the arrangement of the metadata space. > > However, in our case, how does the proposed compiler establish the mapping > from the P4 metadata key to rte_flow without support from the backend > compiler? Yes. We need to change the backend compiler to understand the rte_flow mapping to p4 to avoid any translation cost.
