From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id A80B947D1 for ; Mon, 13 Jun 2016 10:14:32 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bCN3C-0007hr-2W; Mon, 13 Jun 2016 10:16:51 +0200 To: Christian Ehrhardt , David Marchand , dev References: From: Olivier Matz Message-ID: <575E6B60.3030403@6wind.com> Date: Mon, 13 Jun 2016 10:14:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] Question regarding mempool changes impact to XEN PMD 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: Mon, 13 Jun 2016 08:14:32 -0000 Hi Christian, On 06/13/2016 09:34 AM, Christian Ehrhardt wrote: > Hi David, I guess this mail is for me, not for David :) > it seems to be the first time I compiled with > CONFIG_RTE_LIBRTE_PMD_XENVIRT=y sinec the bigger mempool changes around > "587d684d doc: update release notes about mempool allocation". > > I've seen related patch to mempool / xen in that regard "c042ba20 mempool: > rework support of Xen dom0" > > But with above config symbol enabled I got: > drivers/net/xenvirt/rte_xen_lib.c: In function ‘grant_gntalloc_mbuf_pool’: > drivers/net/xenvirt/rte_xen_lib.c:440:69: error: ‘struct rte_mempool’ has > no member named ‘elt_va_start’ > if (snprintf(val_str, sizeof(val_str), "%"PRIxPTR, > (uintptr_t)mpool->elt_va_start) == -1) > ^ > SYMLINK-FILE include/rte_eth_bond.h > mk/internal/rte.compile-pre.mk:126: recipe for target 'rte_xen_lib.o' failed > make[4]: *** [rte_xen_lib.o] Error 1 > make[4]: *** Waiting for unfinished jobs.... > > The change around the mempools is complex, so I don't see on the first look > if that needs a minor or major rework in the xen sources. > I mean I don't want it to compile, but to work and that could be more than > just fixing that changed structure :-) > > So I wanted to ask if you as author would see if it is a trivial change > that has to be made? Sorry, I missed this reference to elt_va_start in my patches. I'm not very familiar with the xen code in dpdk, but from what I see: - in the PMD, grant_gntalloc_mbuf_pool() stores the mempool virtual address in the xen key/value database - in examples/vhost_xen, the function parse_mpool_va() retrieves it - this address is used in new_device() I think the patch would be almost similar to what I did in mlx drivers in this commit: http://dpdk.org/browse/dpdk/commit/?id=84121f1971873c9f45b2939c316c66126d8754a1 or in librte_kni in this commit: http://dpdk.org/browse/dpdk/commit?id=d1d914ebbc2514f334a3ed24057e63c8bb76363d To give more precisions: - before the patchset, mp->elt_va_start was the virtual address of the mempool objects table. It was always virtually contiguous - now, a mempool can be fragmented in several virtually contiguous chunks. In case there is only one chunk, it can be safely replaced by STAILQ_FIRST(&mp->mem_list)->addr (= the virtual address of the first chunk). In case there are more chunks in the mempool, it would require deeper modifications I think. But we should keep in mind that having a virtually fragmented mempool was not possible before the patchset (it would have fail at init). If if fails later in xen code because xen does not support fragmented mempools, there is no regression compared to what we had before. I'll send a draft patch, if you could give it a try, it would be great! Thanks for reporting, Olivier