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 E0FC1568A for ; Wed, 25 Nov 2015 13:02:44 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 25 Nov 2015 04:02:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,342,1444719600"; d="scan'208";a="606890932" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.111]) by FMSMGA003.fm.intel.com with SMTP; 25 Nov 2015 04:02:41 -0800 Received: by (sSMTP sendmail emulation); Wed, 25 Nov 2015 12:02:40 +0025 Date: Wed, 25 Nov 2015 12:02:40 +0000 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20151125120239.GA23268@bricha3-MOBL3> References: <56554B08.3040400@ndsl.kaist.edu> <1711935.0QY3Nxc9zX@xps13> <20151125110020.GA14808@bricha3-MOBL3> <49956413.am4JoMJyVU@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49956413.am4JoMJyVU@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] no hugepage with UIO poll-mode driver 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, 25 Nov 2015 12:02:45 -0000 On Wed, Nov 25, 2015 at 12:03:05PM +0100, Thomas Monjalon wrote: > 2015-11-25 11:00, Bruce Richardson: > > On Wed, Nov 25, 2015 at 11:23:57AM +0100, Thomas Monjalon wrote: > > > 2015-11-25 10:08, Bruce Richardson: > > > > On Wed, Nov 25, 2015 at 03:39:17PM +0900, Younghwan Go wrote: > > > > > Hi Jianfeng, > > > > > > > > > > Thanks for the email. rte mempool was successfully created without any > > > > > error. Now the next problem is that rte_eth_rx_burst() is always returning 0 > > > > > as if there was no packet to receive... Do you have any suggestion on what > > > > > might be causing this issue? In the meantime, I will be digging through > > > > > ixgbe driver code to see what's going on. > > > > > > > > > > Thank you, > > > > > Younghwan > > > > > > > > > > > > > The problem is that with --no-huge we don't have the physical address of the memory > > > > to write to the network card. That's what it's marked as for testing only. > > > > > > Even with rte_mem_virt2phy() + rte_mem_lock_page() ? > > > > > With no-huge, we just set up a single memory segment at startup and set its > > "physaddr" to be the virtual address. > > > > /* hugetlbfs can be disabled */ > > if (internal_config.no_hugetlbfs) { > > addr = mmap(NULL, internal_config.memory, PROT_READ | PROT_WRITE, > > MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); > > if (addr == MAP_FAILED) { > > RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__, > > strerror(errno)); > > return -1; > > } > > mcfg->memseg[0].phys_addr = (phys_addr_t)(uintptr_t)addr; > > rte_mem_virt2phy() does not use memseg.phys_addr but /proc/self/pagemap: > > /* > * the pfn (page frame number) are bits 0-54 (see > * pagemap.txt in linux Documentation) > */ > physaddr = ((page & 0x7fffffffffffffULL) * page_size) > + ((unsigned long)virtaddr % page_size); > Yes, you are right. I was not aware that that function was used as part of the mempool init, but now I see that "rte_mempool_virt2phy()" does indeed call that function if hugepages are disabled, so my bad. /Bruce