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

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

Hi Ori,

On 2/16/22 17:18, Ori Kam wrote:
> Hi Andrew,
> 
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@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@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@nvidia.com>
>>>>> Acked-by: Ori Kam <orika@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.

Andrew.