From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 18F995424 for ; Wed, 25 Nov 2015 14:24:08 +0100 (CET) Received: by wmvv187 with SMTP id v187so256882342wmv.1 for ; Wed, 25 Nov 2015 05:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=Vv28KTjA+zaF8AUtoYhzxXWoQK5S+0xUO2Kg4obulCM=; b=anG5Gfk4lNFR/GrVZja3dji/l9Crm7ChzGG8pNwQYDUEfLBSCQJGhN/e16UJaGPg7d a3yAzHYwdpFGVDbazsgQxATuYNXZP1YO2vbtsJGheOEnuTr5/tEeXGcKU3MofSnIG46D ALcKZz8vTPAGyMkkIsAOX9BInlKoJX3r6L8B0Jm9Xm3oaQ2C8aDGzIZ0Ux43RZ4IfdL0 NWpeoVnKpCangF1AS8ImjqJQjsm+SSHBVFjnjbS4QK2ue4Hv/sBZh1qGSQSxyyyeYzX/ LDnikICDlEnUYky4SsznIjHRMXf4tv5QU6kCS2/0mKMtt1alhkDT5mR5GDAdCY84d1ux FxuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=Vv28KTjA+zaF8AUtoYhzxXWoQK5S+0xUO2Kg4obulCM=; b=HVmD+XBkuQMJgZUf8Sopbc7wMtALHx9DFf9Tezm+c2ovbVE1ImbPt4Hyy4+j8ypjTh ivS/Adrok6G3iXSdVwbPg5eZSQ1wOEUiSDQYM45LqjGONeW3gH9vYdBsl20lOTLDtv/7 jH17518fY/AG0/k2aTXLon3ucmC8GGZBaFf0mVxcCgPS2UMMSqBhS1fgqitITYbaw1AB bW5f5L9mKUe4ylaG93mvNKY8ItrVVmzcUy+AZgPLiFDIDPaSytRZwkjTIecTL+zX4CTw wXjVmf3JZtCe427JzN8770dbTTnKoBXQz1SZA1DMXyxEyVvFWKCm0rX/JLem2G72/X+x JpKw== X-Gm-Message-State: ALoCoQnFyxfDEXENHt0Ldd6iE4kfJqqgsmn4M7XB3Vs/fMa0Eo+Zvi0PBnivTLMo/ZlcwVl2ezsL X-Received: by 10.28.23.83 with SMTP id 80mr4653110wmx.78.1448457847861; Wed, 25 Nov 2015 05:24:07 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id u17sm3569314wmd.8.2015.11.25.05.24.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Nov 2015 05:24:07 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson Date: Wed, 25 Nov 2015 14:22:49 +0100 Message-ID: <5690109.niDVrFKdOE@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20151125120239.GA23268@bricha3-MOBL3> References: <56554B08.3040400@ndsl.kaist.edu> <49956413.am4JoMJyVU@xps13> <20151125120239.GA23268@bricha3-MOBL3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 13:24:08 -0000 2015-11-25 12:02, Bruce Richardson: > 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. Do you think we could move --no-huge in the main section (not only for testing)?