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 0E049A0A0E; Wed, 28 Apr 2021 12:03:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7347141299; Wed, 28 Apr 2021 12:03:32 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id A17BB40147; Wed, 28 Apr 2021 12:03:30 +0200 (CEST) IronPort-SDR: YsZoRi/Ge8b2xMzJKAxNwEn4fzTCCApWWl1MuLWoh8EF6R6gfjXajDJPFzQLQQ7tfuIXW5gYBC SW0FDQw64JVw== X-IronPort-AV: E=McAfee;i="6200,9189,9967"; a="183845889" X-IronPort-AV: E=Sophos;i="5.82,257,1613462400"; d="scan'208";a="183845889" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2021 03:03:28 -0700 IronPort-SDR: Ole2+4PzI0/U+0KElig4fu3zg1uH+AgXWcwYY4Ys3ULgxWRj0G6dQarNuC7LF8VQMhEPPUMJS1 wMRBS3lsElSQ== X-IronPort-AV: E=Sophos;i="5.82,257,1613462400"; d="scan'208";a="423455664" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.241.177]) ([10.213.241.177]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2021 03:03:25 -0700 To: Alvin Zhang , qi.z.zhang@intel.com, qiming.yang@intel.com Cc: dev@dpdk.org, stable@dpdk.org References: <20210425092639.1428-1-alvinx.zhang@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Wed, 28 Apr 2021 11:03:22 +0100 MIME-Version: 1.0 In-Reply-To: <20210425092639.1428-1-alvinx.zhang@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [dpdk-stable] [DPDK] net/ice: fix txq mbuf release mode 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 4/25/2021 10:26 AM, Alvin Zhang wrote: > In some cases, it seems that the txq mbuf vector release mode > is enabled first, and then it is confirmed that the conditions > for using the vector mode are not met. > Hi Alvin, As far as I understand the impact is failure in the Tx vector patch selection, can you please update the patch title to reflect it? Also can you please describe a little more what is "txq mbuf vector release mode" and what is the root cause for it to be enabled first? > This patch puts the txq vector mode startup process after the > condition detection. What is "txq vector mode startup process"? > > Fixes: 28f9002ab67f ("net/ice: add Tx AVX512 offload path") > Cc: stable@dpdk.org > > Signed-off-by: Alvin Zhang > --- > drivers/net/ice/ice_rxtx.c | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c > index 92fbbc1..49abcb2 100644 > --- a/drivers/net/ice/ice_rxtx.c > +++ b/drivers/net/ice/ice_rxtx.c > @@ -3303,13 +3303,6 @@ > if (tx_check_ret >= 0 && > rte_vect_get_max_simd_bitwidth() >= RTE_VECT_SIMD_128) { > ad->tx_vec_allowed = true; > - for (i = 0; i < dev->data->nb_tx_queues; i++) { > - txq = dev->data->tx_queues[i]; > - if (txq && ice_txq_vec_setup(txq)) { > - ad->tx_vec_allowed = false; > - break; > - } > - } > > if (rte_vect_get_max_simd_bitwidth() >= RTE_VECT_SIMD_512 && > rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) == 1 && > @@ -3329,6 +3322,15 @@ > if (!use_avx512 && tx_check_ret == ICE_VECTOR_OFFLOAD_PATH) > ad->tx_vec_allowed = false; > > + if (ad->tx_vec_allowed) { > + for (i = 0; i < dev->data->nb_tx_queues; i++) { > + txq = dev->data->tx_queues[i]; > + if (txq && ice_txq_vec_setup(txq)) { > + ad->tx_vec_allowed = false; > + break; > + } > + } > + } > } else { > ad->tx_vec_allowed = false; > } >