DPDK patches and discussions
 help / color / mirror / Atom feed
From: "XU Liang" <liang.xu@cinfotech.cn>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] 答复: [PATCH] eal: map uio resources after hugepages when the	base_virtaddr is configured.
Date: Wed, 05 Nov 2014 23:49:03 +0800
Message-ID: <01d6ff37-3473-43af-aff3-1183d4c4768a@cinfotech.cn> (raw)
In-Reply-To: C6ECDF3AB251BE4894318F4E4512369780C070FA@IRSMSX109.ger.corp.intel.com

[-- 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

  parent reply	other threads:[~2014-11-05 15:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-05 13:25 [dpdk-dev] " lxu
2014-11-05 15:10 ` Burakov, Anatoly
2014-11-05 15:49 ` XU Liang [this message]
2014-11-05 15:59   ` [dpdk-dev] 答复: " Burakov, Anatoly
2014-11-05 16:10   ` [dpdk-dev] 答复:答复: " XU Liang
2014-11-26  1:46     ` Qiu, Michael
2014-11-26  9:58       ` Burakov, Anatoly
2014-11-06 14:11 ` [dpdk-dev] [PATCH v2] " lxu
2014-11-06 14:27   ` Burakov, Anatoly
2014-11-06 14:48   ` [dpdk-dev] 答复:[PATCH " 徐亮
2014-11-06 14:47 ` [dpdk-dev] [PATCH v3] " lxu
2014-11-06 15:06   ` De Lara Guarch, Pablo
2014-11-06 15:07 ` [dpdk-dev] [PATCH v4] " lxu
2014-11-06 15:12   ` Thomas Monjalon
2014-11-06 15:11 ` lxu
2014-11-06 15:32 ` [dpdk-dev] [PATCH v5] " lxu
2014-11-06 15:41   ` Burakov, Anatoly
2014-11-06 15:58     ` Thomas Monjalon
2014-11-06 16:10       ` Burakov, Anatoly
2014-11-06 17:30         ` Bruce Richardson
2014-11-07  8:01 ` [dpdk-dev] [PATCH v6] " lxu
2014-11-07  9:42   ` Bruce Richardson
2014-11-07  9:47   ` Burakov, Anatoly
2014-11-07  9:57   ` XU Liang
2014-11-07 14:37     ` XU Liang
2014-11-10 11:34   ` [dpdk-dev] [PATCH v7] eal: map PCI memory resources after hugepages Anatoly Burakov
2014-11-10 13:33     ` Burakov, Anatoly
2014-11-11  3:53     ` XU Liang
2014-11-11 10:09     ` [dpdk-dev] [PATCH v8] " Anatoly Burakov
2014-11-13 11:34       ` Burakov, Anatoly
2014-11-13 12:58         ` Bruce Richardson
2014-11-13 13:44           ` Burakov, Anatoly
2014-11-13 13:46       ` Bruce Richardson
2014-11-25 17:17         ` Thomas Monjalon
2014-11-07 14:57 ` [dpdk-dev] [PATCH v7] eal: map uio " lxu
2014-11-07 15:14   ` Burakov, Anatoly
2014-11-07 15:15   ` Thomas Monjalon
2014-11-07 15:19   ` XU Liang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01d6ff37-3473-43af-aff3-1183d4c4768a@cinfotech.cn \
    --to=liang.xu@cinfotech.cn \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git