From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by dpdk.org (Postfix) with ESMTP id 64468324D for ; Tue, 19 Jun 2018 12:23:35 +0200 (CEST) Received: by mail-wm0-f65.google.com with SMTP id v16-v6so19015726wmh.5 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=eVgVDm2oCrwLkqcG6lFM8x+0BkqZYVpNB5iFQJ8dQS+HVV/jrP4IHGnnO9HUDPwhzu AkcPCuzabjkJuy/uBfou5uxjb7aoslXbvy241W5Vf9/QHSPvhVdOLdcY4k5hefdmjK9P gsNHOpGift8hQ65fLSQEKonyRvnWu7Ea1CN5lnJb7ZQZzjRPPvqqMdmFL2I/eKRoxyjA O8PzQcK0oCWMWsSHiDab6PD1y0cSBw95asUYVz/jhHYvmFS/1ls+ofbLyk7YsJscfvI8 Exu6BCyJzKbh7mFAlE6GtSKsitJIj9O3B8g36+nMHw1FC+hdCOjkrAxZH0e9WKHuhppz HkiA== X-Gm-Message-State: APt69E0ZhKqYm/WUzNujPO79YEQvBHoF/w6Rhusx6306pPAzNs0M29uj ormSGRA9NvC+Ol5NfhAja5FBMOnnXHemG9FRnanBnQ== 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-stable] [dpdk-dev] [PATCH] memory: do not use base-virtaddr in secondary processes X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches 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 >