Hi Andrew and Ajit, > -----Original Message----- > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > Sent: Monday, October 11, 2021 4:58 PM > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep > indirect actions on restart > > On 10/7/21 11:16 AM, Dmitry Kozlyuk wrote: > >> -----Original Message----- > >> From: Ajit Khaparde <ajit.khapa...@broadcom.com> > >> Sent: 6 октября 2021 г. 20:13 > >> To: Dmitry Kozlyuk <dkozl...@nvidia.com> > >> Cc: dpdk-dev <dev@dpdk.org>; Matan Azrad <ma...@nvidia.com>; Ori Kam > >> <or...@nvidia.com>; NBU-Contact-Thomas Monjalon > >> <tho...@monjalon.net>; Ferruh Yigit <ferruh.yi...@intel.com>; Andrew > >> Rybchenko <andrew.rybche...@oktetlabs.ru> > >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to > >> keep indirect actions on restart > >> > >> On Wed, Sep 1, 2021 at 1:55 AM Dmitry Kozlyuk <dkozl...@nvidia.com> wrote: > >>> > >>> rte_flow_action_handle_create() did not mention what happens with an > >>> indirect action when a device is stopped, possibly reconfigured, and > >>> started again. It is natural for some indirect actions to be > >>> persistent, like counters and meters; keeping others just saves > >>> application time and complexity. However, not all PMDs can support it. > >>> It is proposed to add a device capability to indicate if indirect > >>> actions are kept across the above sequence or implicitly destroyed. > >>> > >>> It may happen that in the future a PMD acquires support for a type > >>> of indirect actions that it cannot keep across a restart. It is > >>> undesirable to stop advertising the capability so that applications > >>> that don't use actions of the problematic type can still take advantage > >>> of it. > >>> This is why PMDs are allowed to keep only a subset of indirect > >>> actions provided that the vendor mandatorily documents it. > >> Sorry - I am seeing this late. > >> This could become confusing. > >> May be it is better for the PMDs to specify which actions are persistent. > >> How about adding a bit for the possible actions of interest. > >> And then PMDs can set bits for actions which can be persistent across > >> stop, start and reconfigurations? > > > > This approach was considered, but there is a risk of quickly running out of > > capability bits. Each action > would consume one bit plus as many bits as there are special conditions for > it in all the PMDs, because > conditions are likely to be PMD-specific. And the application will anyway > need to consider specific > conditions to know which bit to test, so the meaning of the bits will be > PMD-specific. On the other hand, > PMDs are not expected to exercise this loophole unless absolutely needed. > > Right those bits should be considered as master bits and are not per actions. If there is specific case for a PMD it should solve it by documation or other means.
> > May be we should separate at least transfer and non-transfer rules? Transfer > rules are less configuration > dependent. May be I'm missing something but jut like stated above those are master bits I don't see much use case where the PMD can store transfer rules but not other rules. I assume that if the application uses the transfer mode most of the flows will be in the transfer domain. Best, Ori
