From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) by dpdk.org (Postfix) with ESMTP id D9CB42C65 for ; Mon, 13 Jun 2016 10:31:03 +0200 (CEST) Received: by mail-qt0-f175.google.com with SMTP id c34so32536925qte.0 for ; Mon, 13 Jun 2016 01:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sT0I1FKIeMaEPFlKYfUzjVM9k1N6O/0VV2nBULZ48LA=; b=kPrqHn+rwjbHDQRtZcmiAL3WNnDDd+ib5VplK6XavQQwQSZyJgFg0i0S2UFtMXZs/a zaBtY511mFWnB3mKoPNaCZBeAS/8MBx2ZBAZNqQsF7DRqXqCfE9MlAt+8qlhCig7oqyz jLVfLXYIiT6UbkZmedjMOW+poCAFuHF0Oux9aakDZmihxE75kKHUegG8qNSa9GVcwTGl mhoeRMXhI1Opkcpt1as8GUeY8PqHWP/Tu+fY+KCFE6LMXDcf96x0D8Hj5HwsNiTxYP2F GZmHMi2sknLht3J6fZakmQF11XjdMPqPRE8YDdqNyeUU4kdHoWa+p315tBix6ALrggg8 2y/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sT0I1FKIeMaEPFlKYfUzjVM9k1N6O/0VV2nBULZ48LA=; b=NJBOxleynsP2EeHyY9DCef9IpQHTCthIYTjaPZoBa3i+pnyK4euv6BJFFn+Rf0w6LE ckqRUHjHmBNY3uXb4OJWfXaogtCogc0m5B1baHdopV+s3lUNj3zjxkQ7SYP8flqO/9tU JTXmcaUUHNR6AZzyj5wHLiBYBG9ZzSUE6o9ocDSZT1LeS8xs8+XDMTiT9FrmoVWSxm+9 DaUQa32/2jq/7I2OE1W5rUHSPvnRsJ+2TFke5p6IATe8TJh9AmG0H09X0cnfvvvfZMYc reMYLYyPRlmBkhHjPiH6UT9Y01J2OovfKrJfMRFJWDGMdEw5eoue/ivOsGsZZ7A+85nX nz/w== X-Gm-Message-State: ALyK8tKLxrYCDFbVlwm+jBIzJIq0HzRFhWDdadU/eSBc6/54uN2zAAEy4bdCv2PEaPNnC/Dd7yDJMncSwOZB+DPr X-Received: by 10.237.35.152 with SMTP id j24mr2907620qtc.96.1465806663236; Mon, 13 Jun 2016 01:31:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.162.9 with HTTP; Mon, 13 Jun 2016 01:30:43 -0700 (PDT) In-Reply-To: <575E6B60.3030403@6wind.com> References: <575E6B60.3030403@6wind.com> From: Christian Ehrhardt Date: Mon, 13 Jun 2016 10:30:43 +0200 Message-ID: To: Olivier Matz Cc: David Marchand , dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:31:04 -0000 On Mon, Jun 13, 2016 at 10:14 AM, Olivier Matz wrote: > Hi Christian, > > On 06/13/2016 09:34 AM, Christian Ehrhardt wrote: > > Hi David, > > I guess this mail is for me, not for David :) > Absolutely yes, sorry to both of you to - probably read too much patch headers this morning :-) > > it seems to be the first time I compiled with > > CONFIG_RTE_LIBRTE_PMD_XENVIRT=3Dy sinec the bigger mempool changes arou= nd > > "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 > =E2=80=98grant_gntalloc_mbuf_pool=E2=80=99: > > drivers/net/xenvirt/rte_xen_lib.c:440:69: error: =E2=80=98struct rte_me= mpool=E2=80=99 has > > no member named =E2=80=98elt_va_start=E2=80=99 > > if (snprintf(val_str, sizeof(val_str), "%"PRIxPTR, > > (uintptr_t)mpool->elt_va_start) =3D=3D -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=3D84121f1971873c9f45b2939c316c6612= 6d8754a1 > > or in librte_kni in this commit: > > http://dpdk.org/browse/dpdk/commit?id=3Dd1d914ebbc2514f334a3ed24057e63c8b= b76363d > > 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 (=3D 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. > Ack to that, I only cared about the regression and that I think you covered excellently. To make fragmented pools work would be a task for one who "cares" to use it= . > > I'll send a draft patch, if you could give it a try, it would be great! > I can compile and review the patch, but I neither have a setup to actually run it. Maybe someone else on the list have, please feel encouraged to do so. > Thanks for reporting, > Olivier > >