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 E274137A6 for ; Tue, 19 Jun 2018 13:48:50 +0200 (CEST) Received: by mail-wm0-f65.google.com with SMTP id v131-v6so21482132wma.1 for ; Tue, 19 Jun 2018 04:48:50 -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=l6mTMcvTs1TzDoOTRAk7XmoZgvMMSXkL2Fb+uuLo4Iw=; b=Cyu6m3LdtYMNUZDqQLznzTqXMLahF3R4gTVWYTF1ddp2+4X4zpZq5uP+h0ZcBpnvyT FaqtVMDfyM0Z2JaK/35tE+N0cYEOnSubRprtPOmDCkD6t8baf3CEDDoyS1UihqEO+9oF QCNtzdvc+Qf8TtAuocOz/FpfxOu4LaDQP86KWgB2s4sEBO8EdLMiswgclYvNFuwWngJl SRswFiFzO9OdcJBVSA8PclNxitsnBFkEwJzWjIZA9f+ipECLfaXzrcKM3dDYxhzNGYo3 To2iT5TpOP+qpNLkAfCWah1rnurMEhTIL1czb621WSj+XKFI0+g3BgCDVmxaazWfISJq ZuIw== 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=l6mTMcvTs1TzDoOTRAk7XmoZgvMMSXkL2Fb+uuLo4Iw=; b=KSbJDtXxNyLW8lFZfx1rJ5tTm2zqqO9mvHkT0/+pLabOnwRIXLUSAQgS8R/JpWOilK EuxZ/dloi0WaX37uJOhSXwOBNO1dFXAHNUYm8N4bpUps0dSaiIK6baDzUTis2T+PLoP+ L80JA9jgGEJqsoov8raSCa90MTy49ZhWVxuSxyZuEWsN2BvK8xxG2PyW40OKChiUt0PQ +KIxPJm/AkvUx+eHfW2wrF8JY0Oakfg3P9J86VLJSxTad7W1uVyq4VQ+AoU1SnAOkeN2 yHQu1K+mhlzURkU6RjWqO+9PMcvO8Y5WEr34GNGYEEU3UDWQAzuuUkGdLG8hQxRhrWNB 0kvw== X-Gm-Message-State: APt69E18b5Y9L3YKwhDj/rTqKN7b5yvWwmxXrCUQF1Nin9zRPK4WBsIS cijbwiLdcVNBH6AShYDv2xenNsc1xObiBQqp0iPRZg== X-Google-Smtp-Source: ADUXVKIHlTgi8LBrJCfdea3A6v9LkPKxlpeXan44nEYYEfhrRzqC+gGaUjs8m3psyE/e/ZAIXU2eP3Cl9Mw0DVzm37k= X-Received: by 2002:a50:adfd:: with SMTP id b58-v6mr14543883edd.168.1529408930727; Tue, 19 Jun 2018 04:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:b197:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 04:48:50 -0700 (PDT) In-Reply-To: <01d715f0-50aa-9d66-1cbb-1c5e4af0e3c6@intel.com> References: <1529351589-173939-1-git-send-email-dariuszx.stojaczyk@intel.com> <01d715f0-50aa-9d66-1cbb-1c5e4af0e3c6@intel.com> From: Alejandro Lucero Date: Tue, 19 Jun 2018 12:48:50 +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 11:48:51 -0000 On Tue, Jun 19, 2018 at 11:27 AM, Burakov, Anatoly < anatoly.burakov@intel.com> wrote: > On 19-Jun-18 11:23 AM, Alejandro Lucero wrote: > >> >> >> 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 describes >> 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 packets >> 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 o= f DPDK >> 18.05, --base-virtaddr 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 any 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 co= uld >> have also some sort of limitation. >> > > OK, looking forward to it. > > 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. >> >> > Presumably, device driver would be in the best position to know things > like that, no? Maybe a new device flag and an API to query such things fr= om > all devices? > > Right. I plan to add a per-device DMA mask, just mimicking what the kernel has. > -- > Thanks, > Anatoly >