Re: seeking community input on adapting DPDK to P4Runtime backend

[Jerin Jacob <jerinjacobk@gmail.com>]

On Mon, May 22, 2023 at 10:42 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Ori Kam <orika@nvidia.com>
> > Sent: Thursday, May 18, 2023 10:34 PM
> > To: Zhang, Qi Z <qi.z.zhang@intel.com>; dev@dpdk.org
> > Cc: techboard@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>;
> > Burakov, Anatoly <anatoly.burakov@intel.com>; Wiles, Keith
> > <keith.wiles@intel.com>; Liang, Cunming <cunming.liang@intel.com>; Wu,
> > Jingjing <jingjing.wu@intel.com>; Zhang, Helin <helin.zhang@intel.com>;
> > Mcnamara, John <john.mcnamara@intel.com>; Xu, Rosen
> > <rosen.xu@intel.com>
> > Subject: RE: seeking community input on adapting DPDK to P4Runtime
> > backend

We did some study to use rte_flow on table driven _HW_ (HW has similar
capability to p4 table)
Following are the observations that need improvement in rte_flow.


1) HW engines require more resources for ACL (considering the
algorithmic HW implementation and table size is in handful of
millions),
whereas EM, LPM needs less HW resources, In p4, we have means to
express this, in rte_flow, in general assumption it is ACL.
We may need to express the mode in rte_flow_template_table_create() or
so. Otherwise,
more than one rte_flow_pattern_template* templates
pattern_template_index of rte_flow_async_create() creates
conflicting modes. In p4, mode is associated with a table, and it has
fixed KEY and VALUE.  This area in the rte_flow requires
improvement if we need to use with p4 type HW.

2) rte_flow is purely in working "inline" mode, If CPU core needs to
do lookup on the table created. We require some APIs
to look-aside mode support.

3) Handling of raw action data

a) In p4, Action value is opaque, so maybe we need to have action RAW
where value can be running
number from 0 to VALUE - 1.

b) Expressing the handling compute operation after lookup.
rte_flow_actions are fixed in nature, which
would suffice for a lot of use case. Expressing the following case may
be difficult with rte_flow now.

For example:
value_from_lookup = lookup(packet, key);
if ((packet.filed[x] && value_value_from_lookup) == value_x) {
packet.field[x] += value_y;
packet.field[x] ^= value_z;
}

I think, such general programming paradigm kind of action may need
ePBF kind program to express.
Where we can add new RTE_FLOW_ACTION_LOAD_EPF_PROGRAM to run through a
simple program after table lookup.

Either, we can update the rte_flow to address the cases reported in the thread
or enhance the current rte_table library(which already has a function
pointer based backend) and
create an object using the rte_table API and connect the table object
with rte_flow API.

I think, we should try to enhance rte_flow for more native table
support if possible.