On 10/7/21 11:16 AM, Dmitry Kozlyuk wrote: >> -----Original Message----- >> From: Ajit Khaparde <[email protected]> >> Sent: 6 октября 2021 г. 20:13 >> To: Dmitry Kozlyuk <[email protected]> >> Cc: dpdk-dev <[email protected]>; Matan Azrad <[email protected]>; Ori Kam >> <[email protected]>; NBU-Contact-Thomas Monjalon >> <[email protected]>; Ferruh Yigit <[email protected]>; Andrew >> Rybchenko <[email protected]> >> 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 <[email protected]> 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.
