24/05/2023 17:00, Jerin Jacob:
> 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.
I agree to enhance rte_flow in general.
I suspect that most of features above are already possible
using some unknown properties of rte_flow.
For instance, modifying a packet is possible with
RTE_FLOW_ACTION_TYPE_MODIFY_FIELD.
