On Wed, Oct 20, 2021 at 11:35 PM Dmitry Kozlyuk <dkozl...@oss.nvidia.com> wrote: > > Previously, it was not specified what happens to the flow rules > when the device is stopped, possibly reconfigured, then started. > If flow rules were kept, it could be convenient for application > developers, because they wouldn't need to save and restore them. > However, due to the number of flows and possible creation rate it is > impractical to save all flow rules in DPDK layer. This means that flow > rules persistence really depends on whether PMD and HW can implement it > efficiently. It can also be limited by the rule item and action types, > and its attributes transfer bit (a combination of an item/action type > and a value of the transfer bit is called a ruel feature). > > Add a device capability bit for PMDs that can keep at least some > of the flow rules across restart. Without this capability behavior > is still unspecified and it is declared that the application must > flush the rules before stopping the device. > Allow the application to test for persistence of rules using > a particular feature by attempting to create a flow rule > using that feature when the device is stopped > and checking for the specific error. > This is logical because if the PMD can to create the flow rule > when the device is not started and use it after the start happens, > it is natural that it can move its internal flow rule object > to the same state when the device is stopped and restore the state > when the device is started. > > Rule persistence across a reconfigurations is not required, > because tracking all the rules and configuration-dependent resources > they use may be infeasible. In case a PMD cannot keep the rules > across reconfiguration, it is allowed just to report an error. > Application must then flush the rules before attempting it. > > Signed-off-by: Dmitry Kozlyuk <dkozl...@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khapa...@broadcom.com>
