From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 8A329A0C57;
	Mon,  1 Nov 2021 16:06:25 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 75D70410FE;
	Mon,  1 Nov 2021 16:06:25 +0100 (CET)
Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113])
 by mails.dpdk.org (Postfix) with ESMTP id 91DF4410FE
 for <dev@dpdk.org>; Mon,  1 Nov 2021 16:06:24 +0100 (CET)
Received: from [192.168.1.71] (unknown [188.170.83.209])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 72CED7F707;
 Mon,  1 Nov 2021 18:06:22 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 72CED7F707
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru;
 s=default; t=1635779184;
 bh=zREeRsNlkRDcLrIA9b3qWydxhIeERqrsWs/pX6y9Z2U=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To;
 b=CZv435Fw4Nuq0jFddoqKkCCBECO5IcjtAlc7kO2IfJxkH7MIWJPoKxvqXecdqZboP
 m+epJOzXyT1Yw9ibaFdmlhbk7VVJie9vL4tnUjKwZI2FRV4Sr4rDf/44J4i99sjgil
 6Bebs06AzywERPrmpjK4HhaY1FcKaK5n3cwIDcmo=
To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>, dev@dpdk.org
Cc: Ori Kam <orika@nvidia.com>, Ferruh Yigit <ferruh.yigit@intel.com>,
 Ajit Khaparde <ajit.khaparde@broadcom.com>,
 Somnath Kotur <somnath.kotur@broadcom.com>,
 Nithin Dabilpuram <ndabilpuram@marvell.com>,
 Kiran Kumar K <kirankumark@marvell.com>, Sunil Kumar Kori
 <skori@marvell.com>, Satha Rao <skoteshwar@marvell.com>,
 Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
 Hemant Agrawal <hemant.agrawal@nxp.com>,
 Sachin Saxena <sachin.saxena@oss.nxp.com>,
 Haiyue Wang <haiyue.wang@intel.com>, John Daley <johndale@cisco.com>,
 Hyong Youb Kim <hyonkim@cisco.com>, Gaetan Rivet <grive@u256.net>,
 Ziyang Xuan <xuanziyang2@huawei.com>,
 Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>,
 Guoyang Zhou <zhouguoyang@huawei.com>, "Min Hu (Connor)"
 <humin29@huawei.com>, Yisen Zhuang <yisen.zhuang@huawei.com>,
 Lijun Ou <oulijun@huawei.com>, Beilei Xing <beilei.xing@intel.com>,
 Jingjing Wu <jingjing.wu@intel.com>, Qiming Yang <qiming.yang@intel.com>,
 Qi Zhang <qi.z.zhang@intel.com>, Rosen Xu <rosen.xu@intel.com>,
 Liron Himi <lironh@marvell.com>, Jerin Jacob <jerinj@marvell.com>,
 Rasesh Mody <rmody@marvell.com>,
 Devendra Singh Rawat <dsinghrawat@marvell.com>,
 Jasvinder Singh <jasvinder.singh@intel.com>,
 Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
 Keith Wiles <keith.wiles@intel.com>, Jiawen Wu <jiawenwu@trustnetic.com>,
 Jian Wang <jianwang@trustnetic.com>
References: <20211019123722.3414694-1-dkozlyuk@nvidia.com>
 <20211021063503.3632732-1-dkozlyuk@nvidia.com>
 <20211021063503.3632732-4-dkozlyuk@nvidia.com>
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Message-ID: <8ba989e2-bb50-7533-6037-c934c005c7ae@oktetlabs.ru>
Date: Mon, 1 Nov 2021 18:06:20 +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: <20211021063503.3632732-4-dkozlyuk@nvidia.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v4 3/6] net: advertise no support for keeping
 flow rules
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 10/21/21 9:35 AM, Dmitry Kozlyuk wrote:
> When RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP capability bit is zero,
> the specified behavior is the same as it had been before
> this bit was introduced. Explicitly reset it in all PMDs
> supporting rte_flow API in order to attract the attention
> of maintainers, who should eventually choose to advertise
> the new capability or not. It is already known that
> mlx4 and mlx5 will not support this capability.
> 
> For RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP
> similar action is not performed,
> because no PMD except mlx5 supports indirect actions.
> Any PMD that starts doing so will anyway have to consider
> all relevant API, including this capability.
> 
> Suggested-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>

I'm sorry, but I still think that the patch is confusing.
No strong opinion, but personally I'd go without it.