From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id 5C76B31FC for ; Tue, 19 Jun 2018 12:23:35 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id o13-v6so18944006wmf.4 for ; Tue, 19 Jun 2018 03:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=otzTg7uNTZYRSLm09k3Q1u4NZG0NTwG9PucSqFVgk+k=; b=qlWix/Ny8qpO2sW8FYGAO/sdIjZEsI8sCN+t0k6unJzB1OzMqaYPniSIRevairhNpJ gGfknNyeUEkpuIl6WlZZO2pM7Hob9n+YsOuUt65Lmd3N1y4iYefj7eK6wrC43/jtnFor NBi1quuW+SXTBHX+YtAXqMo8rz5AA6E04BvShjHZujap4IpTa8DsJspa4JyIFHrFphzl nkU4dNqmTU5x80yQ8pm7bbIy7NuB1UoaRHj7h5nBKpYc1nmrdPoqR2FM+dZDs1Q7fR/Q XagX9gciBubl6pQ9Y4B1AMC6DtjplphLYNxGTFsZAd1phQAueZ+HcSlVkOaHTvtyqA4c ZXwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=otzTg7uNTZYRSLm09k3Q1u4NZG0NTwG9PucSqFVgk+k=; b=UIKry3uh9ZNDXIUs7rnAA2gDsNIazn4c6krZl02ITXvYFg410Tr1fwnVS3zJo5f9QS boN81sAzpGj9XpYCs0HYAqce5xc6Dqtwcc0VH7Rjhm5xIB3GDOheYyyfrVi+CpHG+uNA 5kjNLSqQnfCWD113JDY2875WX9bPf+MUvpk2FjxPxPuh6GdgUbDQeEWmbcysusB4p8Vh Rzbx31Fe/ZYSkQ1QNvdU5p88DOZ+jiske1xn28xC4OKsLnuLQmI0jwTKxJH/UTvjGcPj 2a64BHvMEFtM9AJmeSV6carnH+G+V7RmUff57SfAA7qDejsE8MfmSwKX3tbeObL9Kgs9 bKew== X-Gm-Message-State: APt69E20AU0aV5QVk9JVw8pk8CpmN6xQyLub3l0G/QvX9k9ffggn6fGR CvUEsg1VkR0hqEYYzmMI6AIb/cqFs5nye/GFe4B2vw== X-Google-Smtp-Source: ADUXVKJHpUEjKZgDT6zwJGo2jqC6qw0b496AxveFFh40UvMQasI3GEq9vPGtIP9s1ZcF4Ps/9wxEbCNaiyOOHYKYt8U= X-Received: by 2002:a50:9622:: with SMTP id y31-v6mr14395087eda.32.1529403815141; Tue, 19 Jun 2018 03:23:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:b197:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 03:23:34 -0700 (PDT) In-Reply-To: References: <1529351589-173939-1-git-send-email-dariuszx.stojaczyk@intel.com> From: Alejandro Lucero Date: Tue, 19 Jun 2018 11:23:34 +0100 Message-ID: To: "Burakov, Anatoly" Cc: "Stojaczyk, DariuszX" , dev , "stable@dpdk.org" 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] [PATCH] memory: do not use base-virtaddr in secondary processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 10:23:35 -0000 On Tue, Jun 19, 2018 at 10:24 AM, Burakov, Anatoly < anatoly.burakov@intel.com> wrote: > On 18-Jun-18 9:12 PM, Stojaczyk, DariuszX wrote: > >> >> >> -----Original Message----- >>> From: Alejandro Lucero [mailto:alejandro.lucero@netronome.com] >>> Sent: Monday, June 18, 2018 9:33 PM >>> >>> On Mon, Jun 18, 2018 at 8:03 PM, Stojaczyk, DariuszX >>> > >>> wrote: >>> >>> Can you point me out to an NFP guide or some code that describe= s >>> this in more detail? >>> >>> >>> >>> As I said, I'm working on a RFC. I will send something shortly. But I >>> could give >>> you an advance: the hugepages needs to be mapped below certain virtual >>> address, 1TB, and I'm afraid that includes the primary and also the >>> secondary processes. At least if any process can send or receive packet= s >>> to/from a NFP. >>> >>> >>> >> Thanks, I'm pretty sure we're safe, then. >> >> >>> If we're talking about base-virtaddr for hugepages, then that's >>> always >>> inherited from the primary process, regardless of what base-virtaddr is >>> supplied to the secondary. >>> >>> >>> >>> >>> But, is not your patch avoiding to use that base-virtaddr for secondary >>> processes? >>> >> >> I see now that the patch name is slightly misleading. Maybe I shouldn=E2= =80=99t >> pick such a catchy title. Let me clarify: As of DPDK 18.05, --base-virta= ddr >> param for secondary process applications only affects that shadow memseg >> metadata that's not useful for anyone, but can still do a lot of harm. >> Hugepage memory in secondary processes is always mapped to the same >> addresses the primary process uses. >> >> D. >> >> > Hi Alejandro, > > To solve this problem, one possible approach would be to have maximum VA > address, and allocate memory downwards, rather than upwards. Is that by a= ny > chance approximate contents of your RFC? :) > > Hi Anatoly, There's a lot of space below 1TB, but this specific upper limit is just in the NFP case. My RFC will propose a generic solution assuming there could be other devices in the future, and not just NIC devices, which could have also some sort of limitation. The problem is, those devices limitations can not be known at memory initialization time, so some sort of check is required afterwards, once the devices have been proved and initialised. > -- > Thanks, > Anatoly >