[dpdk-dev] 答复： [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.

["XU Liang" <liang.xu@cinfotech.cn>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6452 bytes --]

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 <anatoly.burakov@intel.com>发送时间：2014年11月5日(星期三) 23:10收件人：徐亮 <liang.xu@cinfotech.cn>，dev@dpdk.org <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: <jbshaw@ecsmtp.pdx.intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id 8D43A7F2D
 for <dev@dpdk.org>; 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 <jeffrey.b.shaw@intel.com>
To: Gyumin <hkm73560@gmail.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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