From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B7EB0A04B6; Thu, 17 Sep 2020 13:03:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 936FE1D5EF; Thu, 17 Sep 2020 13:03:28 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 3B8F01D5EE for ; Thu, 17 Sep 2020 13:03:26 +0200 (CEST) IronPort-SDR: W4kKOvEOyD7uF14sdk72+Ueh1Eqkj2pndruk5vkGe8fM5j9ulu+/56+laCyc63nZxGseBA3Du9 TzPtOyGXXuGg== X-IronPort-AV: E=McAfee;i="6000,8403,9746"; a="158975636" X-IronPort-AV: E=Sophos;i="5.76,436,1592895600"; d="scan'208";a="158975636" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 04:03:23 -0700 IronPort-SDR: HZYoBkTlSBWlDd0ezIx7U95w9+Kd9y2EaMYWgDn6uYfv6Hb/T17KhRj1hyYYjrc46s+ZjmYkxk qdEn8ZmR82dA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,436,1592895600"; d="scan'208";a="483701178" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga005.jf.intel.com with ESMTP; 17 Sep 2020 04:03:22 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 17 Sep 2020 04:03:21 -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.1713.5; Thu, 17 Sep 2020 19:03:19 +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.1713.004; Thu, 17 Sep 2020 19:03:19 +0800 From: "Zhang, Qi Z" To: "Guo, Jia" , "Yang, Qiming" , "Xing, Beilei" , "Wu, Jingjing" , "Wang, Haiyue" CC: "Zhao1, Wei" , "Richardson, Bruce" , "dev@dpdk.org" , "Zhang, Helin" , "mb@smartsharesystems.com" , "Yigit, Ferruh" , "stephen@networkplumber.org" , "barbette@kth.se" , "Han, YingyaX" Thread-Topic: [PATCH v4 4/5] net/ice: fix vector rx burst for ice Thread-Index: AQHWjMjHr7AeNDW3RkqAL5RrybG1/Klsl94Q Date: Thu, 17 Sep 2020 11:03:19 +0000 Message-ID: References: <20200827075452.1751-1-jia.guo@intel.com> <20200917075834.60034-1-jia.guo@intel.com> <20200917075834.60034-5-jia.guo@intel.com> In-Reply-To: <20200917075834.60034-5-jia.guo@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.108.32.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 4/5] net/ice: fix vector rx burst for ice X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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: Guo, Jia > Sent: Thursday, September 17, 2020 3:59 PM > To: Yang, Qiming ; Xing, Beilei > ; Zhang, Qi Z ; Wu, Jingjing > ; Wang, Haiyue > Cc: Zhao1, Wei ; Richardson, Bruce > ; dev@dpdk.org; Guo, Jia ; > Zhang, Helin ; mb@smartsharesystems.com; Yigit, > Ferruh ; stephen@networkplumber.org; > barbette@kth.se; Han, YingyaX > Subject: [PATCH v4 4/5] net/ice: fix vector rx burst for ice >=20 > The limitation of burst size in vector rx was removed, since it should re= trieve as > much received packets as possible. And also the scattered receive path sh= ould > use a wrapper function to achieve the goal of burst maximizing. And do so= me > code cleaning for vector rx path. >=20 > Bugzilla ID: 516 > Fixes: c68a52b8b38c ("net/ice: support vector SSE in Rx") > Fixes: ae60d3c9b227 ("net/ice: support Rx AVX2 vector") >=20 > Signed-off-by: Jeff Guo > Tested-by: Yingya Han > --- > drivers/net/ice/ice_rxtx.h | 1 + > drivers/net/ice/ice_rxtx_vec_avx2.c | 23 ++++++------ > drivers/net/ice/ice_rxtx_vec_sse.c | 56 +++++++++++++++++++---------- > 3 files changed, 49 insertions(+), 31 deletions(-) >=20 > diff --git a/drivers/net/ice/ice_rxtx.h b/drivers/net/ice/ice_rxtx.h inde= x > 2fdcfb7d0..3ef5f300d 100644 > --- a/drivers/net/ice/ice_rxtx.h > +++ b/drivers/net/ice/ice_rxtx.h > @@ -35,6 +35,7 @@ > #define ICE_MAX_RX_BURST ICE_RXQ_REARM_THRESH > #define ICE_TX_MAX_FREE_BUF_SZ 64 > #define ICE_DESCS_PER_LOOP 4 > +#define ICE_DESCS_PER_LOOP_AVX 8 No need to expose this if no external link, better to keep all avx stuff in= side avx.c >=20 > #define ICE_FDIR_PKT_LEN 512 >=20 > diff --git a/drivers/net/ice/ice_rxtx_vec_avx2.c > b/drivers/net/ice/ice_rxtx_vec_avx2.c > index be50677c2..843e4f32a 100644 > --- a/drivers/net/ice/ice_rxtx_vec_avx2.c > +++ b/drivers/net/ice/ice_rxtx_vec_avx2.c > @@ -29,7 +29,7 @@ ice_rxq_rearm(struct ice_rx_queue *rxq) > __m128i dma_addr0; >=20 > dma_addr0 =3D _mm_setzero_si128(); > - for (i =3D 0; i < ICE_DESCS_PER_LOOP; i++) { > + for (i =3D 0; i < ICE_DESCS_PER_LOOP_AVX; i++) { > rxep[i].mbuf =3D &rxq->fake_mbuf; > _mm_store_si128((__m128i *)&rxdp[i].read, > dma_addr0); > @@ -132,12 +132,17 @@ ice_rxq_rearm(struct ice_rx_queue *rxq) > ICE_PCI_REG_WRITE(rxq->qrx_tail, rx_id); } >=20 > +/** > + * vPMD raw receive routine, only accept(nb_pkts >=3D > +ICE_DESCS_PER_LOOP_AVX) > + * > + * Notice: > + * - nb_pkts < ICE_DESCS_PER_LOOP_AVX, just return no packet > + * - floor align nb_pkts to a ICE_DESCS_PER_LOOP_AVX power-of-two */ The comment is misleading, it looks like we are going to floor align nb_pkt= s to 2^8, better to reword . > static inline uint16_t > _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq, struct rte_mbuf > **rx_pkts, > uint16_t nb_pkts, uint8_t *split_packet) { -#define > ICE_DESCS_PER_LOOP_AVX 8 > - > const uint32_t *ptype_tbl =3D rxq->vsi->adapter->ptype_tbl; > const __m256i mbuf_init =3D _mm256_set_epi64x(0, 0, > 0, rxq->mbuf_initializer); > @@ -603,10 +608,6 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue > *rxq, struct rte_mbuf **rx_pkts, > return received; > } >=20 > -/* > - * Notice: > - * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet > - */ > uint16_t > ice_recv_pkts_vec_avx2(void *rx_queue, struct rte_mbuf **rx_pkts, > uint16_t nb_pkts) > @@ -616,8 +617,6 @@ ice_recv_pkts_vec_avx2(void *rx_queue, struct > rte_mbuf **rx_pkts, >=20 > /** > * vPMD receive routine that reassembles single burst of 32 scattered > packets > - * Notice: > - * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet > */ Why we need to remove this? is it still true for this function? > static uint16_t > ice_recv_scattered_burst_vec_avx2(void *rx_queue, struct rte_mbuf > **rx_pkts, @@ -626,6 +625,9 @@ ice_recv_scattered_burst_vec_avx2(void > *rx_queue, struct rte_mbuf **rx_pkts, > struct ice_rx_queue *rxq =3D rx_queue; > uint8_t split_flags[ICE_VPMD_RX_BURST] =3D {0}; >=20 > + /* split_flags only can support max of ICE_VPMD_RX_BURST */ > + nb_pkts =3D RTE_MIN(nb_pkts, ICE_VPMD_RX_BURST); Is this necessary? the only consumer of this function is ice_recv_scattere= d_pkts_vec_avx2,=20 I think nb_pkts <=3D ICE_VPMD_RX_BURST it already be guaranteed. > + > /* get some new buffers */ > uint16_t nb_bufs =3D _ice_recv_raw_pkts_vec_avx2(rxq, rx_pkts, nb_pkts, > split_flags); > @@ -657,9 +659,6 @@ ice_recv_scattered_burst_vec_avx2(void *rx_queue, > struct rte_mbuf **rx_pkts, >=20 > /** > * vPMD receive routine that reassembles scattered packets. > - * Main receive routine that can handle arbitrary burst sizes > - * Notice: > - * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet > */ Why we need to remove this? isn't it the main routine that be able to handl= e arbitrary burst size? Btw, I will suggest all AVX2 changes can be in a separate patch, because th= is looks like some code clean and fix. its not related with the main purpose of the patch set.