I think the base_virtadd will be carefully selected by user when they need it. So maybe it's not a real problem.  :>The real reason is I can't find a easy way to get the end address of hugepages. Can you give me some suggestions ?------------------------------------------------------------------发件人：Burakov, Anatoly 发送时间：2014年11月5日(星期三) 23:10收件人：徐亮 ，dev@dpdk.org 主　题：RE: [dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured. I have a slight problems with this patch. The base_virtaddr doesn't necessarily correspond to an address that 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 requested a base-virtaddr, everything will get mapped at exactly that address. We also 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_virtaddr + internal_config.memory - there may be holes, for whatever reasons. Also, Thanks, Anatoly -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of lxu Sent: Wednesday, November 5, 2014 1:25 PM To: dev@dpdk.org Subject: [dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured. --- lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c index 7e62266..bc7ed3a 100644 --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c @@ -289,6 +289,11 @@ pci_uio_map_resource(struct rte_pci_device *dev) struct rte_pci_addr *loc = &dev->addr; struct mapped_pci_resource *uio_res; struct pci_map *maps; + static void * requested_addr = NULL; + if (internal_config.base_virtaddr && NULL == requested_addr) { + requested_addr = (uint8_t *) internal_config.base_virtaddr + + internal_config.memory; + } dev->intr_handle.fd = -1; dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; @@ -371,10 +376,12 @@ pci_uio_map_resource(struct rte_pci_device *dev) if (maps[j].addr != NULL) fail = 1; else { - mapaddr = pci_map_resource(NULL, fd, (off_t)offset, + mapaddr = pci_map_resource(requested_addr, fd, (off_t)offset, (size_t)maps[j].size); if (mapaddr == NULL) fail = 1; + else if (NULL != requested_addr) + requested_addr = (uint8_t *)mapaddr + maps[j].size; } if (fail) { -- 1.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_PTHRESH6 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