From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1134-217.mail.aliyun.com (out1134-217.mail.aliyun.com [42.120.134.217]) by dpdk.org (Postfix) with ESMTP id C0AF57E80 for ; Wed, 5 Nov 2014 16:39:43 +0100 (CET) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.02629256|-1; FP=0|0|0|0|0|-1|-1|-1; HT=r41g08151; MF=liang.xu@cinfotech.cn; PH=DW; RN=2; RT=2; SR=0; Received: from WS-web (liang.xu@cinfotech.cn[222.65.239.251]) by r41g06024.xy2.aliyun.com at Wed, 05 Nov 2014 23:49:03 +0800 Date: Wed, 05 Nov 2014 23:49:03 +0800 From: "XU Liang" To: "=?UTF-8?B?QnVyYWtvdiwgQW5hdG9seQ==?=" , "dev@dpdk.org" Message-ID: <01d6ff37-3473-43af-aff3-1183d4c4768a@cinfotech.cn> X-Mailer: Alimail-Mailagent revision 2667797 MIME-Version: 1.0 References: <1415193919-17361-1-git-send-email-liang.xu@cinfotech.cn>, C6ECDF3AB251BE4894318F4E4512369780C070FA@IRSMSX109.ger.corp.intel.com In-Reply-To: C6ECDF3AB251BE4894318F4E4512369780C070FA@IRSMSX109.ger.corp.intel.com x-aliyun-mail-creator: Webmail4_2670074_M3LTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTBfMCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzM4LjAuMjEyNS4xMTEgU2FmYXJpLzUzNy4zNg==vN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] =?utf-8?b?562U5aSN77yaIFtQQVRDSF0gZWFsOiBtYXAgdWlvIHJl?= =?utf-8?q?sources_after_hugepages_when_the=09base=5Fvirtaddr_is_configure?= =?utf-8?q?d=2E?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: XU Liang List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:39:45 -0000 I think the base_virtadd will be carefully selected by user when they need it.= So maybe it's not a real problem. =C2=A0:>The real reason is I can't find a e= asy way to get the end address of hugepages. Can you give me some=C2=A0suggest= ions ?------------------------------------------------------------------=E5=8F= =91=E4=BB=B6=E4=BA=BA=EF=BC=9ABurakov, Anatoly =E5=8F= =91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2014=E5=B9=B411=E6=9C=885=E6=97=A5(=E6=98= =9F=E6=9C=9F=E4=B8=89) 23:10=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A=E5=BE=90=E4=BA= =AE =EF=BC=8Cdev@dpdk.org =E4=B8=BB=E3=80= =80=E9=A2=98=EF=BC=9ARE: [dpdk-dev] [PATCH] eal: map uio resources after hugep= ages when the base_virtaddr is configured.=0AI have a slight problems with thi= s patch.=0A=0AThe base_virtaddr doesn't necessarily correspond to an address t= hat everything gets mapped to. It's a "hint" of sorts, that may or may not be = taken into account by mmap. Therefore we can't simply assume that if we reques= ted a base-virtaddr, everything will get mapped at exactly that address. We al= so can't assume that hugepages will be ordered one after the other and occupy = neatly all the contiguous virtual memory between base_virtaddr and base_virtad= dr + internal_config.memory - there may be holes, for whatever reasons.=0A=0AA= lso, =0A=0AThanks,=0AAnatoly=0A=0A-----Original Message-----=0AFrom: dev [mail= to:dev-bounces@dpdk.org] On Behalf Of lxu=0ASent: Wednesday, November 5, 2014 = 1:25 PM=0ATo: dev@dpdk.org=0ASubject: [dpdk-dev] [PATCH] eal: map uio resource= s after hugepages when the base_virtaddr is configured.=0A=0A---=0A lib/librte= _eal/linuxapp/eal/eal_pci_uio.c | 9 ++++++++-=0A 1 file changed, 8 insertions(= +), 1 deletion(-)=0A=0Adiff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c = b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c=0Aindex 7e62266..bc7ed3a 100644=0A= --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c=0A+++ b/lib/librte_eal/linuxap= p/eal/eal_pci_uio.c=0A@@ -289,6 +289,11 @@ pci_uio_map_resource(struct rte_pci= _device *dev)=0A struct rte_pci_addr *loc =3D &dev->addr;=0A struct mapped_p= ci_resource *uio_res;=0A struct pci_map *maps;=0A+ static void * requested_ad= dr =3D NULL;=0A+ if (internal_config.base_virtaddr && NULL =3D=3D requested_ad= dr) {=0A+ requested_addr =3D (uint8_t *) internal_config.base_virtaddr =0A+ = + internal_config.memory;=0A+ }=0A =0A dev->intr_handle.fd =3D -1;=0A dev->= intr_handle.type =3D RTE_INTR_HANDLE_UNKNOWN; @@ -371,10 +376,12 @@ pci_uio_ma= p_resource(struct rte_pci_device *dev)=0A if (maps[j].addr !=3D NULL)=0A = fail =3D 1;=0A else {=0A- mapaddr =3D pci_map_resource(NULL, fd, (off_= t)offset,=0A+ mapaddr =3D pci_map_resource(requested_addr, fd, (off_t)offse= t,=0A (size_t)maps[j].size);=0A if (mapaddr =3D=3D NULL)=0A fai= l =3D 1;=0A+ else if (NULL !=3D requested_addr)=0A+ requested_addr =3D = (uint8_t *)mapaddr + maps[j].size;=0A }=0A =0A if (fail) {=0A--=0A1.9.1 >From jbshaw@ecsmtp.pdx.intel.com Wed Nov 5 16:40:40 2014 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 8D43A7F2D for ; Wed, 5 Nov 2014 16:40:39 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 05 Nov 2014 07:42:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,320,1413270000"; d="scan'208";a="617616041" Received: from plxs0284.pdx.intel.com ([10.25.97.128]) by fmsmga001.fm.intel.com with ESMTP; 05 Nov 2014 07:48:20 -0800 Received: from plxv1143.pdx.intel.com (plxv1143.pdx.intel.com [10.25.98.50]) by plxs0284.pdx.intel.com with ESMTP id sA5FmKfG027858; Wed, 5 Nov 2014 07:48:20 -0800 Received: from plxv1143.pdx.intel.com (localhost [127.0.0.1]) by plxv1143.pdx.intel.com with ESMTP id sA5FmKC5015874; Wed, 5 Nov 2014 07:48:20 -0800 Received: (from jbshaw@localhost) by plxv1143.pdx.intel.com with œ id sA5FmJB0015821; Wed, 5 Nov 2014 07:48:20 -0800 Date: Wed, 5 Nov 2014 07:48:19 -0800 From: Jeff Shaw To: Gyumin Message-ID: <20141105154819.GA25599@plxv1143.pdx.intel.com> References: <545972BF.9080100@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545972BF.9080100@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Intel 82599 tx_conf setting 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: Wed, 05 Nov 2014 15:40:40 -0000 On Wed, Nov 05, 2014 at 09:43:43AM +0900, Gyumin wrote: > Hi > > I've read the Intel 82599 official manual and I found that optimal > PTHRESH is the tx descriptor buffer size - N (N is CPU cache line > divided by 16). This is sometimes true, but not always. I believe you are referring to section "7.2.3.4.1 Transmit Descriptor Fetch and Write-back Settings" in the datasheet. You'll see the PTHRESH, HTHRESH, and WTHRESH parameters should be tuned to for your workload. You should try a few combinations of parameters (starting with the defaults) to see which is really optimal for your application. > 1. I guess the size of the tx descriptor buffer is 128. Isn't it right? > Where is the size of the tx descriptor buffer in the official manual? The wording in the manual may be a bit confusing. You will see the manual refers to the "on-chip descriptor buffer size". This is where the NIC stores descriptors which were fetched from the actual descriptor ring in host memory. Section "7.2.3.3 Transmit Descriptor Ring" states that the size of the on-chip descriptor buffer size per queue is 40. > > 2. What it means that the TX_PTHRESH=36 in the testpmd.c? > If the size of tx descriptor buffer is 128 then optimal thresholds > to minimize latency are pthresh=4(cache line / 16), hthresh=0 and > wthresh=0. Is there something I missed? Since the on-chip descriptor buffer size is 40, it is clear that we have chosen reasonable defaults since 40 minus 4 is 36. I recommend you test a few different values to see how these parameters impact the performance characteristics of your workload. > > > Thanks. You're welcome. -Jeff