DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Ori Kam <orika@nvidia.com>, Dmitry Kozlyuk <dkozlyuk@nvidia.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: dpdk-dev <dev@dpdk.org>, Matan Azrad <matan@nvidia.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions on restart
Date: Tue, 12 Oct 2021 12:15:23 +0300	[thread overview]
Message-ID: <28f4a819-a9c7-e363-991b-b78f89fcf162@oktetlabs.ru> (raw)
In-Reply-To: <DM8PR12MB54002EEF9F66B76DB8D0EA20D6B59@DM8PR12MB5400.namprd12.prod.outlook.com>

On 10/11/21 6:53 PM, Ori Kam wrote:
> Hi Andrew and Ajit,
> 
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@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@broadcom.com>
>>>> Sent: 6 октября 2021 г. 20:13
>>>> To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
>>>> Cc: dpdk-dev <dev@dpdk.org>; Matan Azrad <matan@nvidia.com>; Ori Kam
>>>> <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
>>>> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew
>>>> Rybchenko <andrew.rybchenko@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@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.

Documentation does not solve the problem since it can't be
automated. So, it just help to solve case-by-case.

> 
>>
>> 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.

Most likely different HW blocks are responsible for transfer
and non-transfer rules. So, I can easily imagine that one
could be preserved across restart, but another can't.

Anyway, I'm just trying to understand. Not a blocker.

Also have you considered to make it controllable by the
application. I.e. PMD advertises a capability and it is
responsibility of the application to use it or not.
May be it is excessive. In theory application can check
the flag and do flush before or just after stop if it
does not want to preserve rules.

Andrew.

  reply	other threads:[~2021-10-12  9:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  8:55 [dpdk-dev] [RFC PATCH 0/2] Flow entities behavior across port restart Dmitry Kozlyuk
2021-09-01  8:55 ` [dpdk-dev] [RFC PATCH 1/2] ethdev: add capability to keep flow rules on restart Dmitry Kozlyuk
2021-09-01  8:55 ` [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions " Dmitry Kozlyuk
2021-09-27 11:21   ` Dmitry Kozlyuk
2021-10-06 17:12   ` Ajit Khaparde
2021-10-07  8:16     ` Dmitry Kozlyuk
2021-10-11 13:58       ` Andrew Rybchenko
2021-10-11 15:53         ` Ori Kam
2021-10-12  9:15           ` Andrew Rybchenko [this message]
2021-10-12 10:26             ` Ori Kam
2021-10-12 10:41               ` Andrew Rybchenko
2021-10-13  8:36                 ` Dmitry Kozlyuk
2021-10-11 15:57         ` Dmitry Kozlyuk
2021-10-05 17:23 ` [dpdk-dev] [RFC PATCH 0/2] Flow entities behavior across port restart Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=28f4a819-a9c7-e363-991b-b78f89fcf162@oktetlabs.ru \
    --to=andrew.rybchenko@oktetlabs.ru \
    --cc=ajit.khaparde@broadcom.com \
    --cc=dev@dpdk.org \
    --cc=dkozlyuk@nvidia.com \
    --cc=ferruh.yigit@intel.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).