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