> -----Original Message----- > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > Sent: 11 октября 2021 г. 16:58 > To: Dmitry Kozlyuk <dkozl...@nvidia.com>; Ajit Khaparde > <ajit.khapa...@broadcom.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> > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep > indirect > actions on restart > > External email: Use caution opening links or attachments > > > 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. > > > > May be we should separate at least transfer and non-transfer rules? Transfer > rules are less configuration dependent.
Do you suggest splitting the bit from patch 1/2 in two? Or did you mean indirect actions with only "transfer" bit set and suggest splitting the bit from this patch in two?
