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.

Reply via email to