From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id A6D07282 for ; Fri, 7 Apr 2017 10:26:59 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP; 07 Apr 2017 01:26:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,164,1488873600"; d="scan'208";a="84612242" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.140]) by orsmga005.jf.intel.com with SMTP; 07 Apr 2017 01:26:56 -0700 Received: by (sSMTP sendmail emulation); Fri, 07 Apr 2017 09:26:55 +0100 Date: Fri, 7 Apr 2017 09:26:54 +0100 From: Bruce Richardson To: "Zhang, Qi Z" Cc: "Zhang, Helin" , "dev@dpdk.org" , "Yigit, Ferruh" Message-ID: <20170407082654.GB11816@bricha3-MOBL3.ger.corp.intel.com> References: <20170403143944.17719-1-bruce.richardson@intel.com> <20170406113217.28236-1-bruce.richardson@intel.com> <20170406113217.28236-2-bruce.richardson@intel.com> <039ED4275CED7440929022BC67E7061153088B73@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039ED4275CED7440929022BC67E7061153088B73@SHSMSX103.ccr.corp.intel.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.0 (2017-02-23) Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/i40e: eliminate mbuf write on rearm 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: , X-List-Received-Date: Fri, 07 Apr 2017 08:27:00 -0000 On Thu, Apr 06, 2017 at 05:24:44PM +0100, Zhang, Qi Z wrote: > Hi Bruce: > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > > Sent: Thursday, April 6, 2017 7:32 PM > > To: Zhang, Helin > > Cc: dev@dpdk.org; Yigit, Ferruh ; Richardson, Bruce > > > > Subject: [dpdk-dev] [PATCH v2 1/2] net/i40e: eliminate mbuf write on rearm > > > > With the mbuf rework, we now have 8 contiguous bytes to be rearmed in the > > mbuf just before the 8-bytes of olflags. If we don't do the rearm write inside > > the descriptor ring replenishment function, and delay it to receiving the > > packet, we can do a single 16B write inside the RX function to set both the > > rearm data, and the flags together. > > > > Signed-off-by: Bruce Richardson > > --- > > V2: fix a checkpatch warning. One warning remains, which is being left > > as-is as the code line in question is being removed by patch 2. > > --- > > drivers/net/i40e/i40e_rxtx_vec_sse.c | 46 > > +++++++++++++++++++++--------------- > > 1 file changed, 27 insertions(+), 19 deletions(-) > > > > diff --git a/drivers/net/i40e/i40e_rxtx_vec_sse.c > > b/drivers/net/i40e/i40e_rxtx_vec_sse.c > > index fdd4a34..c43d1c3 100644 > > --- a/drivers/net/i40e/i40e_rxtx_vec_sse.c > > +++ b/drivers/net/i40e/i40e_rxtx_vec_sse.c > > @@ -82,19 +82,10 @@ i40e_rxq_rearm(struct i40e_rx_queue *rxq) > > /* Initialize the mbufs in vector, process 2 mbufs in one loop */ > > for (i = 0; i < RTE_I40E_RXQ_REARM_THRESH; i += 2, rxep += 2) { > > __m128i vaddr0, vaddr1; > > - uintptr_t p0, p1; > > > > mb0 = rxep[0].mbuf; > > mb1 = rxep[1].mbuf; > > > > - /* Flush mbuf with pkt template. > > - * Data to be rearmed is 6 bytes long. > > - */ > > - p0 = (uintptr_t)&mb0->rearm_data; > > - *(uint64_t *)p0 = rxq->mbuf_initializer; > > - p1 = (uintptr_t)&mb1->rearm_data; > > - *(uint64_t *)p1 = rxq->mbuf_initializer; > > - > > /* load buf_addr(lo 64bit) and buf_physaddr(hi 64bit) */ > > vaddr0 = _mm_loadu_si128((__m128i *)&mb0->buf_addr); > > vaddr1 = _mm_loadu_si128((__m128i *)&mb1->buf_addr); @@ > > -125,6 +116,13 @@ i40e_rxq_rearm(struct i40e_rx_queue *rxq) > > I40E_PCI_REG_WRITE(rxq->qrx_tail, rx_id); } > > > > +static inline void > > +desc_to_olflags_v(struct i40e_rx_queue *rxq, __m128i descs[4] > > __rte_unused, > > + struct rte_mbuf **rx_pkts) > > > Should we change the function name? since its scope is changed. > I'm Ok with all the other part. > > Thanks > Qi > Yes, it perhaps should, though it's not a big deal IMHO. Alternatively, the function should be changed to return the flags values as an output and we do the writes themselves in the main rx function. /Bruce