From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 23616C322 for ; Tue, 16 Jun 2015 13:56:06 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 16 Jun 2015 04:56:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,626,1427785200"; d="scan'208";a="588772415" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by orsmga003.jf.intel.com with ESMTP; 16 Jun 2015 04:56:05 -0700 Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 16 Jun 2015 19:56:04 +0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 16 Jun 2015 19:56:03 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.246]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.46]) with mapi id 14.03.0224.002; Tue, 16 Jun 2015 19:55:56 +0800 From: "Qiu, Michael" To: "Chen, Jing D" , "dev@dpdk.org" Thread-Topic: [PATCH 1/6] fm10k: Fix improper RX buffer size assignment Thread-Index: AQHQmecH5qYpK83AEk+ubY+FIayA8g== Date: Tue, 16 Jun 2015 11:55:55 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E602860469C467@SHSMSX101.ccr.corp.intel.com> References: <1432887044-24777-1-git-send-email-jing.d.chen@intel.com> <1432887044-24777-2-git-send-email-jing.d.chen@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "He, Shaopeng" Subject: Re: [dpdk-dev] [PATCH 1/6] fm10k: Fix improper RX buffer size assignment X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 11:56:07 -0000 Tested-by: Michael Qiu =0A= =0A= - OS: Fedora20 3.11.10-301=0A= - GCC: gcc version 4.8.3 2014911=0A= - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz=0A= - NIC: Ethernet controller: Intel Corporation Device 15a4 (rev 01)=0A= - Default x86_64-native-linuxapp-gcc configuration=0A= =0A= =0A= On 5/29/2015 4:11 PM, Chen, Jing D wrote:=0A= > From: "Chen Jing D(Mark)" =0A= >=0A= > As RX buffer is aligned to 512B within mbuf, some bytes are reserved=0A= > for this purpose, and the worst case could be 511B. But SRR reg=0A= > assumes all buffers have the same size. In order to fill the gap,=0A= > we'll have to consider the worsst case and assume 512B is reserved.=0A= > If we don't do so, it's possible for HW to overwrite data to next=0A= > mbuf.=0A= >=0A= > Signed-off-by: Chen Jing D(Mark) =0A= > ---=0A= > drivers/net/fm10k/fm10k.h | 5 +++--=0A= > drivers/net/fm10k/fm10k_ethdev.c | 12 ++++++++++--=0A= > 2 files changed, 13 insertions(+), 4 deletions(-)=0A= >=0A= > diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h=0A= > index 0e31796..ad7a7d1 100644=0A= > --- a/drivers/net/fm10k/fm10k.h=0A= > +++ b/drivers/net/fm10k/fm10k.h=0A= > @@ -191,7 +191,8 @@ struct fm10k_tx_queue {=0A= > =0A= > /* enforce 512B alignment on default Rx DMA addresses */=0A= > #define MBUF_DMA_ADDR_DEFAULT(mb) \=0A= > - ((uint64_t) RTE_ALIGN(((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM), 512)= )=0A= > + ((uint64_t) RTE_ALIGN(((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM),\=0A= > + FM10K_RX_DATABUF_ALIGN))=0A= > =0A= > static inline void fifo_reset(struct fifo *fifo, uint32_t len)=0A= > {=0A= > @@ -263,7 +264,7 @@ fm10k_addr_alignment_valid(struct rte_mbuf *mb)=0A= > uint64_t boundary1, boundary2;=0A= > =0A= > /* 512B aligned? */=0A= > - if (RTE_ALIGN(addr, 512) =3D=3D addr)=0A= > + if (RTE_ALIGN(addr, FM10K_RX_DATABUF_ALIGN) =3D=3D addr)=0A= > return 1;=0A= > =0A= > /* 8B aligned, and max Ethernet frame would not cross a 4KB boundary? *= /=0A= > diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_e= thdev.c=0A= > index 275c19c..a5e09a0 100644=0A= > --- a/drivers/net/fm10k/fm10k_ethdev.c=0A= > +++ b/drivers/net/fm10k/fm10k_ethdev.c=0A= > @@ -41,7 +41,6 @@=0A= > #include "fm10k.h"=0A= > #include "base/fm10k_api.h"=0A= > =0A= > -#define FM10K_RX_BUFF_ALIGN 512=0A= > /* Default delay to acquire mailbox lock */=0A= > #define FM10K_MBXLOCK_DELAY_US 20=0A= > #define UINT64_LOWER_32BITS_MASK 0x00000000ffffffffULL=0A= > @@ -426,6 +425,15 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)=0A= > /* Configure the Rx buffer size for one buff without split */=0A= > buf_size =3D (uint16_t)(rte_pktmbuf_data_room_size(rxq->mp) -=0A= > RTE_PKTMBUF_HEADROOM);=0A= > + /* As RX buffer is aligned to 512B within mbuf, some bytes are=0A= > + * reserved for this purpose, and the worst case could be 511B.=0A= > + * But SRR reg assumes all buffers have the same size. In order=0A= > + * to fill the gap, we'll have to consider the worst case and=0A= > + * assume 512B is reserved. If we don't do so, it's possible=0A= > + * for HW to overwrite data to next mbuf.=0A= > + */=0A= > + buf_size -=3D FM10K_RX_DATABUF_ALIGN;=0A= > +=0A= > FM10K_WRITE_REG(hw, FM10K_SRRCTL(i),=0A= > buf_size >> FM10K_SRRCTL_BSIZEPKT_SHIFT);=0A= > =0A= > @@ -909,7 +917,7 @@ mempool_element_size_valid(struct rte_mempool *mp)=0A= > RTE_PKTMBUF_HEADROOM;=0A= > =0A= > /* account for up to 512B of alignment */=0A= > - min_size -=3D FM10K_RX_BUFF_ALIGN;=0A= > + min_size -=3D FM10K_RX_DATABUF_ALIGN;=0A= > =0A= > /* sanity check for overflow */=0A= > if (min_size > mp->elt_size)=0A= =0A=