From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 55258A034F; Mon, 11 Oct 2021 15:58:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D35D640E0F; Mon, 11 Oct 2021 15:58:23 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id BAC0640E01 for ; Mon, 11 Oct 2021 15:58:22 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 3039A7F508; Mon, 11 Oct 2021 16:58:22 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 3039A7F508 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633960702; bh=Kzo9CFWb2NYRqHuQqXsIA6fGGxZi8C9lbhNoloT78vI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Ugx5s2WgiXK2P4rM29ih82Q/aFGYUgNU0uQhQ1LXMxzcOw2kbeG+3H2KATzh5MMTT /qgcz+1aPqtyGALC/5sazHBLkCyPUlJ/hxi6NHSBep5VJQg4Qje3r+BhacOHROLmwQ qrLabZcyS5TOMVEPeC0rLqbiDhBFJb7DsYa2u1Io= To: Dmitry Kozlyuk , Ajit Khaparde Cc: dpdk-dev , Matan Azrad , Ori Kam , NBU-Contact-Thomas Monjalon , Ferruh Yigit References: <20210901085516.3647814-1-dkozlyuk@nvidia.com> <20210901085516.3647814-3-dkozlyuk@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <5b4d7e66-80f3-8099-2a81-ea6e20ec70ba@oktetlabs.ru> Date: Mon, 11 Oct 2021 16:58:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions on restart X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/7/21 11:16 AM, Dmitry Kozlyuk wrote: >> -----Original Message----- >> From: Ajit Khaparde >> Sent: 6 октября 2021 г. 20:13 >> To: Dmitry Kozlyuk >> Cc: dpdk-dev ; Matan Azrad ; Ori Kam >> ; NBU-Contact-Thomas Monjalon >> ; Ferruh Yigit ; Andrew >> Rybchenko >> 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 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.