[PATCH v5 02/10] ethdev: add flow item/action templates

[Ori Kam]

Hi Andrew,

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
> Sent: Thursday, February 17, 2022 12:45 PM
> Subject: Re: [PATCH v5 02/10] ethdev: add flow item/action templates
> 
> Hi Ori,
> 
> On 2/16/22 17:18, Ori Kam wrote:
> > Hi Andrew,
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
> >> Subject: Re: [PATCH v5 02/10] ethdev: add flow item/action templates
> >>
> >> On 2/12/22 01:25, Alexander Kozyrev wrote:
> >>> On Fri, Feb 11, 2022 6:27 Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru> wrote:
> >>>> On 2/11/22 05:26, Alexander Kozyrev wrote:
> >>>>> Treating every single flow rule as a completely independent and separate
> >>>>> entity negatively impacts the flow rules insertion rate. Oftentimes in an
> >>>>> application, many flow rules share a common structure (the same item mask
> >>>>> and/or action list) so they can be grouped and classified together.
> >>>>> This knowledge may be used as a source of optimization by a PMD/HW.
> >>>>>
> >>>>> The pattern template defines common matching fields (the item mask) without
> >>>>> values. The actions template holds a list of action types that will be used
> >>>>> together in the same rule. The specific values for items and actions will
> >>>>> be given only during the rule creation.
> >>>>>
> >>>>> A table combines pattern and actions templates along with shared flow rule
> >>>>> attributes (group ID, priority and traffic direction). This way a PMD/HW
> >>>>> can prepare all the resources needed for efficient flow rules creation in
> >>>>> the datapath. To avoid any hiccups due to memory reallocation, the maximum
> >>>>> number of flow rules is defined at the table creation time.
> >>>>>
> >>>>> The flow rule creation is done by selecting a table, a pattern template
> >>>>> and an actions template (which are bound to the table), and setting unique
> >>>>> values for the items and actions.
> >>>>>
> >>>>> Signed-off-by: Alexander Kozyrev <akozyrev at nvidia.com>
> >>>>> Acked-by: Ori Kam <orika at nvidia.com>
> >>
> >> [snip]
> >>
> >
> > [Snip]
> >
> >>>>> + *
> >>>>> + * The pattern template defines common matching fields without values.
> >>>>> + * For example, matching on 5 tuple TCP flow, the template will be
> >>>>> + * eth(null) + IPv4(source + dest) + TCP(s_port + d_port),
> >>>>> + * while values for each rule will be set during the flow rule creation.
> >>>>> + * The number and order of items in the template must be the same
> >>>>> + * at the rule creation.
> >>>>> + *
> >>>>> + * @param port_id
> >>>>> + *   Port identifier of Ethernet device.
> >>>>> + * @param[in] template_attr
> >>>>> + *   Pattern template attributes.
> >>>>> + * @param[in] pattern
> >>>>> + *   Pattern specification (list terminated by the END pattern item).
> >>>>> + *   The spec member of an item is not used unless the end member is used.
> >>>>
> >>>> Interpretation of the pattern may depend on transfer vs non-transfer
> >>>> rule to be used. It is essential information and we should provide it
> >>>> when pattern template is created.
> >>>>
> >>>> The information is provided on table stage, but it is too late.
> >>>
> >>> Why is it too late? Application knows which template goes to which table.
> >>> And the pattern is generic to accommodate anything, user just need to put it
> >>> into the right table.
> >>
> >> Because it is more convenient to handle it when individual
> >> template is processed. Otherwise error reporting will be
> >> complicated since it could be just one template which is
> >> wrong.
> >>
> >> Otherwise, I see no point to have driver callbacks
> >> template creation API. I can do nothing here since
> >> I have no enough context. What's the problem to add
> >> the context?
> >>
> >
> > The idea is that the same template can be used in different
> > domains (ingress/egress and transfer)
> > May be we can add on which domains this template is expected to be used.
> > What do you think?
> 
> I see. IMHO if application is going to use the same template
> in transfer and non-transfer rules, it is not a problem to
> register it twice. Otherwise, if PMD needs the information and
> template handling differs a lot in transfer and non-transfer
> case, handling should be postponed and should be done on
> table definition. In this case, we cannot provide feedback
> to application which template it cannot handle. Even if the
> information is somehow encoded in flow error, encoding must
> be defined and it still could be inconvenient for the
> application to handle it.
> 
> Yes, I agree that it is better to fully specify domain
> including ingress and egress, not just transfer/non-transfer.
> 
So lets add the 3 domains.

> Andrew.

Thanks,
Ori