On Wed, Oct 20, 2021 at 11:35 PM Dmitry Kozlyuk <dkozl...@oss.nvidia.com> wrote: > > rte_flow_action_handle_create() did not mention what happens > with an indirect action when a device is stopped and started again. > It is natural for some indirect actions, like counter, to be persistent. > Keeping others at least saves application time and complexity. > However, not all PMDs can support it, or the support may be limited > by particular action kinds, that is, combinations of action type > and the value of the transfer bit in its configuration. > > Add a device capability to indicate if at least some indirect actions > are kept across the above sequence. Without this capability the behavior > is still unspecified, and application is required to destroy > the indirect actions before stopping the device. > In the future, indirect actions may not be the only type of objects > shared between flow rules. The capability bit intends to cover all > possible types of such objects, hence its name. > > Declare that the application can test for the persistence > of a particular indirect action kind by attempting to create > an indirect action of that kind when the device is stopped > and checking for the specific error type. > This is logical because if the PMD can to create an indirect action > when the device is not started and use it after the start happens, > it is natural that it can move its internal flow shared object > to the same state when the device is stopped and restore the state > when the device is started. > > Indirect action persistence across a reconfigurations is not required. > In case a PMD cannot keep the indirect actions across reconfiguration, > it is allowed just to report an error. > Application must then flush the indirect actions before attempting it. > > Signed-off-by: Dmitry Kozlyuk <dkozl...@nvidia.com> Acked-by: Ajit Khaparde <ajit.khapa...@broadcom.com>
>
