Hi Andrew, > -----Original Message----- > From: Andrew Rybchenko <andrew.rybche...@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.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. > So lets add the 3 domains.
> Andrew. Thanks, Ori
