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 6CFD7A04B7; Fri, 18 Sep 2020 05:20:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D21DF1D70E; Fri, 18 Sep 2020 05:20:24 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 135B01D70C for ; Fri, 18 Sep 2020 05:20:22 +0200 (CEST) IronPort-SDR: RcV0cRJPANBhYacA3f2QA+E3kMyn72z43O3j1iaXNC/Vc4Lcl/YFAs+vziOcRMsnr9VXqTSnfE 4CAyGvLJ2YVw== X-IronPort-AV: E=McAfee;i="6000,8403,9747"; a="160772171" X-IronPort-AV: E=Sophos;i="5.77,273,1596524400"; d="scan'208";a="160772171" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 20:20:17 -0700 IronPort-SDR: 0KTgS6Yow+47MKb3PA/g4O8XTQp3ygRlNqddzPvpw8L18aJhSUo2rkmaI4hNm0i85ayXHPYk+b ns4V1hMgLn1A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,273,1596524400"; d="scan'208";a="336649936" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga008.jf.intel.com with ESMTP; 17 Sep 2020 20:20:15 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by fmsmsx602.amr.corp.intel.com (10.18.126.82) 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 20:20:14 -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; Fri, 18 Sep 2020 11:20:12 +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; Fri, 18 Sep 2020 11:20:12 +0800 From: "Guo, Jia" To: "Zhang, Qi Z" , "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: AQHWjMjH2B1LKjMdsECgm//ok5rFe6lsJJ+AgAGOBOA= Date: Fri, 18 Sep 2020 03:20:12 +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: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 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 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" Hi, qi > -----Original Message----- > From: Zhang, Qi Z > Sent: Thursday, September 17, 2020 7:03 PM > 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 > Subject: RE: [PATCH v4 4/5] net/ice: fix vector rx burst for ice >=20 >=20 >=20 > > -----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 > > > > The limitation of burst size in vector rx was removed, since it should > > retrieve as much received packets as possible. And also the scattered > > receive path should use a wrapper function to achieve the goal of > > burst maximizing. And do some code cleaning for vector rx path. > > > > Bugzilla ID: 516 > > Fixes: c68a52b8b38c ("net/ice: support vector SSE in Rx") > > Fixes: ae60d3c9b227 ("net/ice: support Rx AVX2 vector") > > > > 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(-) > > > > diff --git a/drivers/net/ice/ice_rxtx.h b/drivers/net/ice/ice_rxtx.h > > index 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 >=20 > No need to expose this if no external link, better to keep all avx stuff = inside > avx.c >=20 Ok, so define it in avx.c is the best choice if avx should not in rxtx.h. > > > > #define ICE_FDIR_PKT_LEN 512 > > > > 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; > > > > 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); } > > > > +/** > > + * 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 */ >=20 > The comment is misleading, it looks like we are going to floor align nb_p= kts to > 2^8, better to reword . >=20 It should be, agree. > > 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; > > } > > > > -/* > > - * 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, > > > > /** > > * vPMD receive routine that reassembles single burst of 32 scattered > > packets > > - * Notice: > > - * - nb_pkts < ICE_DESCS_PER_LOOP, just return no packet > > */ >=20 > Why we need to remove this? is it still true for this function? >=20 The reason is that this comment is in the calling function " _ice_recv_raw_= pkts_vec_avx2" which process the related thing, no need to add it more and = more in the caller function.=20 > > 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}; > > > > + /* split_flags only can support max of ICE_VPMD_RX_BURST */ > > + nb_pkts =3D RTE_MIN(nb_pkts, ICE_VPMD_RX_BURST); >=20 > Is this necessary? the only consumer of this function is > ice_recv_scattered_pkts_vec_avx2, I think nb_pkts <=3D > ICE_VPMD_RX_BURST it already be guaranteed. The reason is that we remove "nb_pkts <=3D ICE_VPMD_RX_BURST" and in this f= unction split_flags have a limit for ICE_VPMD_RX_BURST, so a checking is ne= ed in the function. > > + > > /* 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, > > > > /** > > * 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 > > */ >=20 > Why we need to remove this? isn't it the main routine that be able to han= dle > arbitrary burst size? >=20 The question is why we need to said the arbitrary sizes if we process and r= eturn what we could receive packet for maximum? It is not only useless comm= ent but also maybe bring some confuse I think.=20 > Btw, I will suggest all AVX2 changes can be in a separate patch, because = this > looks like some code clean and fix. > its not related with the main purpose of the patch set. I consider it and ask any objection before, so totally I am not disagree on= separate it, but I think if the purpose of the patch set is to clean some= misleading for vec(sse/avx) burst, it could still be on a set even separat= e it to patch.=20