[dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions on restart

[Ori Kam]

Hi Andrew and Ajit,

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko at 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.khaparde at broadcom.com>
> >> Sent: 6 октября 2021 г. 20:13
> >> To: Dmitry Kozlyuk <dkozlyuk at nvidia.com>
> >> Cc: dpdk-dev <dev at dpdk.org>; Matan Azrad <matan at nvidia.com>; Ori Kam
> >> <orika at nvidia.com>; NBU-Contact-Thomas Monjalon
> >> <thomas at monjalon.net>; Ferruh Yigit <ferruh.yigit at intel.com>; Andrew
> >> Rybchenko <andrew.rybchenko at 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 <dkozlyuk at 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