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 5A145A04C7; Fri, 18 Sep 2020 07:39:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3C5DA1D71F; Fri, 18 Sep 2020 07:39:45 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 8B0081D71D for ; Fri, 18 Sep 2020 07:39:43 +0200 (CEST) IronPort-SDR: b/svC9WEN0HDwUMBnV3LFc0BtaqUM6DyR+kJun7yRITa56dcVbW3zE0o8HQqNQM4BR7QPh8kJF 5rLZgWs20Omw== X-IronPort-AV: E=McAfee;i="6000,8403,9747"; a="244698291" X-IronPort-AV: E=Sophos;i="5.77,273,1596524400"; d="scan'208";a="244698291" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 22:39:41 -0700 IronPort-SDR: dMMxHC9GhosemYyB7Nstr5pCxmp7TvSBxvcKZbcpa3v0P3OPT6MQKWC/zYTENL1Cq+9Nk1QNDt QTYyqxLlYgoQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,273,1596524400"; d="scan'208";a="332459776" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by fmsmga004.fm.intel.com with ESMTP; 17 Sep 2020 22:39:41 -0700 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) 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 22:39:41 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX605.ccr.corp.intel.com (10.109.6.215) 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 13:39:40 +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 13:39:40 +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/Klsl94QgACdsQCAAIgbYP//jn8AgACTfuA= Date: Fri, 18 Sep 2020 05:39:39 +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> <3600603ea748465c85e28f71befcfa9e@intel.com> In-Reply-To: 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 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: Friday, September 18, 2020 12:41 PM > To: Zhang, Qi Z ; Yang, Qiming > ; Xing, Beilei ; Wu, Jingji= ng > ; 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 > > -----Original Message----- > > From: Zhang, Qi Z > > Sent: Friday, September 18, 2020 11:41 AM > > 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 > > > > > > > > > -----Original Message----- > > > From: Guo, Jia > > > Sent: Friday, September 18, 2020 11:20 AM > > > 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 > > > Subject: RE: [PATCH v4 4/5] net/ice: fix vector rx burst for ice > > > > > > 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 > > > > > > > > > > > > > > > > > -----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 > > > > > > > > No need to expose this if no external link, better to keep all avx > > > > stuff inside avx.c > > > > > > > > > > Ok, so define it in avx.c is the best choice if avx should not in rxt= x.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 */ > > > > > > > > The comment is misleading, it looks like we are going to floor > > > > align nb_pkts to 2^8, better to reword . > > > > > > > > > > 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 > > > > > */ > > > > > > > > Why we need to remove this? is it still true for this function? > > > > > > > > > > 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. > > > > I think you remove related comment from the calling function also :) > > > > Also I think better to keep this even it's a little bit duplicate, > > that help people to understand the internal logic > > > > > > > > > > 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); > > > > > > > > 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 function split_flags have a limit for ICE_VPMD_RX_BURST, so a > > > checking is need in the function. > > > > Can't get this, could tell me is there any case that nb_pkts > > > ICE_VPMD_RX_BURST? > > >=20 > I know we just set the hard value here and only one case usage, but I thi= nk only > the caller know what would be the input param, but the calling should not= know > the input param will be, even there is no any caller but the calling stil= l need to > be complete. It's in data path where performance is sensitive and also this is just an i= nternal function, we know all the detail, so skip unnecessary route is reas= onable,=20 to avoid bugs and give necessary warning for future scale, I think RTE_ASSE= RT is the right way. >=20 > > > > > > > > > > + > > > > > /* 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 > > > > > */ > > > > > > > > Why we need to remove this? isn't it the main routine that be able > > > > to handle arbitrary burst size? > > > > > > > > > > The question is why we need to said the arbitrary sizes if we > > > process and return what we could receive packet for maximum? It is > > > not only useless comment but also maybe bring some confuse I think. > > > > Yes arbitrary size description can be removed, as this is assumed to > > be the default behavior. > > But the description for nb_pkts should still be kept. > > > > > > > > > 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 separate it to patch. > > > > I will not be insist on patch separate, but if you separate them, some > > of fixes can be merged early and no need to wait for those part need mo= re > review. >=20 > Ok, seems that there still something discuss on the code cleaning patch, = let me > separate it for better review.