From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A0E2C433EF for ; Wed, 20 Oct 2021 10:08:34 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 679AD611C7 for ; Wed, 20 Oct 2021 10:08:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 679AD611C7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=oktetlabs.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 86CD040687; Wed, 20 Oct 2021 12:08:32 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 9189540142 for ; Wed, 20 Oct 2021 12:08:31 +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 C65C57F530; Wed, 20 Oct 2021 13:08:30 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru C65C57F530 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634724510; bh=rrx7qWqgwyboJ7AzdoJf+hu7JTo1rmDx34oX/13kY1A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=MkjPR/KZ1z1XxmQPCRWlaDhIkoQWCIu6mSu9j59aG5y9YN19p+o7QDUPTBxBUu4IR Bs29cG9fqoT8hr3xCxi6ZhLsYwUmlt08/m0aC5miMuSh7x4iBJW7SwNQ5aY8EfjCea 31+pru1h9JEdb22iT6fXxpEzCIrsFKXUGZrxZp4Q= To: Dmitry Kozlyuk , dev@dpdk.org Cc: Ferruh Yigit , Ajit Khaparde , Somnath Kotur , Nithin Dabilpuram , Kiran Kumar K , Sunil Kumar Kori , Satha Rao , Rahul Lakkireddy , Hemant Agrawal , Sachin Saxena , Haiyue Wang , John Daley , Hyong Youb Kim , Gaetan Rivet , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , "Min Hu (Connor)" , Yisen Zhuang , Lijun Ou , Beilei Xing , Jingjing Wu , Qiming Yang , Qi Zhang , Rosen Xu , Liron Himi , Jerin Jacob , Rasesh Mody , Devendra Singh Rawat , Jasvinder Singh , Cristian Dumitrescu , Keith Wiles , Jiawen Wu , Jian Wang References: <20211015161822.3099818-1-dkozlyuk@nvidia.com> <20211019123722.3414694-1-dkozlyuk@nvidia.com> <20211019123722.3414694-4-dkozlyuk@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <4c5ca636-cebe-3e4a-81db-456c15cf1a48@oktetlabs.ru> Date: Wed, 20 Oct 2021 13:08:30 +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: <20211019123722.3414694-4-dkozlyuk@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/19/21 3:37 PM, 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 > Signed-off-by: Dmitry Kozlyuk [snip] > diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c > index aa7e7fdc85..1a6e0128ff 100644 > --- a/drivers/net/bnxt/bnxt_ethdev.c > +++ b/drivers/net/bnxt/bnxt_ethdev.c > @@ -1009,6 +1009,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev, > dev_info->speed_capa = bnxt_get_speed_capabilities(bp); > dev_info->dev_capa = RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP | > RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP; > + dev_info->dev_capa &= ~RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP; Sorry, but here and everywhere below I see no point to cleanup the bit explicitly when it is not actually set. [snip]