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 52017A0579; Thu, 8 Apr 2021 10:57:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 34FCA141178; Thu, 8 Apr 2021 10:57:32 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id DAC2640138 for ; Thu, 8 Apr 2021 10:57:30 +0200 (CEST) IronPort-SDR: mP1g/B0g9iGhAXUtkBGYfWPbCOrP3FXwTDoyd5GycP+tL+0wNZTdKPgx3Hy4kgg9WFHxydhCaY LjFQ1+b6NM7w== X-IronPort-AV: E=McAfee;i="6000,8403,9947"; a="193537734" X-IronPort-AV: E=Sophos;i="5.82,205,1613462400"; d="scan'208";a="193537734" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2021 01:57:29 -0700 IronPort-SDR: Roeef2yxcVxYb8ryU3LGIon0fLySscXFr1xfQrApHCAdbbDXKnAn23T/J5UGy73zlJJDJ/qh/R LYHxtonn8Bcw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,205,1613462400"; d="scan'208";a="422147326" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga008.jf.intel.com with ESMTP; 08 Apr 2021 01:57:29 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 8 Apr 2021 01:57:28 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX601.ccr.corp.intel.com (10.109.6.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 8 Apr 2021 16:57:26 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.2106.013; Thu, 8 Apr 2021 16:57:26 +0800 From: "Zhang, Qi Z" To: "Yang, MurphyX" , "dev@dpdk.org" CC: "Yang, Qiming" , "Guo, Jia" , "Xing, Beilei" , "Yang, SteveX" , "Zhang, RobinX" Thread-Topic: [PATCH] net/i40e: fix mbuf fast free wrong check Thread-Index: AQHXK3mK1Q1KSoH61EmtRY1ZaO3sVaqqUeRw Date: Thu, 8 Apr 2021 08:57:26 +0000 Message-ID: <4cd3ec47b57c4a8e91685a21c0633968@intel.com> References: <20210407063729.67731-1-murphyx.yang@intel.com> In-Reply-To: <20210407063729.67731-1-murphyx.yang@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix mbuf fast free wrong check 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" > -----Original Message----- > From: Yang, MurphyX > Sent: Wednesday, April 7, 2021 2:37 PM > To: dev@dpdk.org > Cc: Yang, Qiming ; Guo, Jia ; > Xing, Beilei ; Zhang, Qi Z ;= Yang, > SteveX ; Zhang, RobinX ; > Yang, MurphyX > Subject: [PATCH] net/i40e: fix mbuf fast free wrong check >=20 > If no offload flags are set, then 0 =3D=3D 0 & is true. > This means that if DEV_TX_OFFLOAD_MBUF_FAST_FREE is not set (and no > other flags are set) then this check will still enable `tx_simple_allowed= `. >=20 > This patch adds the 'offloads' flag not equal zero to avoid this scenario= . >=20 > Bugzilla ID: 665 > Fixes: 399421100e08 ("net/i40e: fix missing mbuf fast free offload") >=20 > Signed-off-by: Murphy Yang > --- > drivers/net/i40e/i40e_rxtx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c = index > b3d7765e3b..1450b228ca 100644 > --- a/drivers/net/i40e/i40e_rxtx.c > +++ b/drivers/net/i40e/i40e_rxtx.c > @@ -3345,7 +3345,7 @@ i40e_set_tx_function_flag(struct rte_eth_dev *dev, > struct i40e_tx_queue *txq) >=20 > /* Use a simple Tx queue if possible (only fast free is allowed) */ > ad->tx_simple_allowed =3D > - (txq->offloads =3D=3D > + (txq->offloads !=3D 0 && txq->offloads =3D=3D > (txq->offloads & DEV_TX_OFFLOAD_MBUF_FAST_FREE) && I don't think this is correct. Why simple_tx can't be selected if no DEV_TX_OFFLOAD_MBUF_FAST_FREE is requ= ired? Actually, the original code means, the max Tx offload that simple_tx suppor= t is DEV_TX_OFFLOAD_MBUF_FAST_FREE, you can't have more than it, but cannot= have it. > txq->tx_rs_thresh >=3D RTE_PMD_I40E_TX_MAX_BURST); > ad->tx_vec_allowed =3D (ad->tx_simple_allowed && > -- > 2.17.1