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 A2AF51559 for ; Mon, 18 Jun 2018 19:21:43 +0200 (CEST) Received: by mail-wm0-f65.google.com with SMTP id j15-v6so17119384wme.0 for ; Mon, 18 Jun 2018 10:21:43 -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=h4MSvRCo4L2Q97vWBi8H4lhWIpGQoOD7hFSEH3Qju6Y=; b=qv/43hSIk6CV2d7QyzVQirYbsao6lFoYF3a9yezCWBysjIgY289w8/oyzWA69yZfdi JSpp38KaJamn8cjw1MrLGn3KzgaEkhW+DfO325riurD4i3/e3T1PQYNwng/wHUmc9VjL yw1lp/nESpeGf/M6jVMiqgshc3V6BnLHhes9hR/MPuS+8Bd+qUn9FI36HYwBjs7URRyj 5klpEDNgmXXmRBDZml+mqJaA4PfY/IZph9dq9BWskQdrqRmVzLImkJdx5ts98Xyt5csJ GcdrnfynUZyooWvsDXWRTCTkgpNTvpfgVLIM0/KWKBJfnpWc/UNcIhFcrBfo+iB28QL4 kxEQ== 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=h4MSvRCo4L2Q97vWBi8H4lhWIpGQoOD7hFSEH3Qju6Y=; b=LABmGktflG8/V/OCoovgJhtsN08IpPM403gWtL+JPcXTDvd2sD1eYbXQWu5zgVHR9v DBIvXEbHxNjvvWl24vq3iikij0hF6gNQWv6GWxbt7Vqk4IICnllJhsyWNd4EQmZfX02i r/LzgKsa5nt9cGJkXSlIGykpkrPaBwgyQVzOlNLlG5tWEng4VONv2qaYkurfKnBC0UnU EcZcuRG8go3E47PTRWuOscEZt5cRuS1cQ851yKLi+dKFgAUK5uMjMvhkYKoGH9eQzJYy yat3Dzx8U2KAOU9Nbzjlpwxf0G9TaJirIHwtZfPcJaYGTnfMW63xAAqhmEKx9KrLBfcb bX1A== X-Gm-Message-State: APt69E049E6Hcitxs3KcxE7IioDQpNLDTYxnptpfEjtAvJuA5XZI9S2v gm00eE0es1XYMXzsmJZN2pU33mEIHRHScud9ihPjWA== X-Google-Smtp-Source: ADUXVKINYN/T1OihtG276jUq3hdeaASVoJkTtIqwPWnXPg46VfDhlzgevmkNYbjwkjdtxvP+cSyTMqgBeQsI2oe3xuk= X-Received: by 2002:a50:8e13:: with SMTP id 19-v6mr11787449edw.101.1529342503392; Mon, 18 Jun 2018 10:21:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:b197:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 10:21:42 -0700 (PDT) In-Reply-To: <1529351589-173939-1-git-send-email-dariuszx.stojaczyk@intel.com> References: <1529351589-173939-1-git-send-email-dariuszx.stojaczyk@intel.com> From: Alejandro Lucero Date: Mon, 18 Jun 2018 18:21:42 +0100 Message-ID: To: Dariusz Stojaczyk Cc: dev , Anatoly Burakov , stable@dpdk.org Content-Type: text/plain; charset="UTF-8" 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: Mon, 18 Jun 2018 17:21:43 -0000 On Mon, Jun 18, 2018 at 8:53 PM, Dariusz Stojaczyk < dariuszx.stojaczyk@intel.com> wrote: > Since secondary process' address space is highly dictated > by the primary process' mappings, it doesn't make much > sense to use base-virtaddr for secondary processes. > > This patch is intended to fix PCI resource mapping > in secondary processes using the same base-virtaddr > as their primary processes. PCI uses the end of the hugepage > memory area to map all resources. [pci_find_max_end_va()] > It works for primary processes, but can't be mapped 1:1 > by secondary ones, as the same addresses are currently always > occupied by shadow memseg lists, which were created with > eal_get_virtual_area(NULL, ...). > > Should not be better to handle these allocations being aware about the problem for secondary processes? I do not know exactly what are the (other) reasons behind base-virtaddr, but it turns out NFP requires this to be used when DPDK apps executed by non-root users. I'm working on a RFC for handling our specific case, that could also be required for other devices, and this change would make the NFP unusable for the secondary processes. > ``` > PRIMARY PROCESS > 0x6e00e00000 388K rw-s- fbarray_memseg-2048k-1-3 > 0x6e01000000 16777216K r---- [ anon ] > 0x7201000000 16K rw-s- resource0 > > SECONDARY PROCESS > 0x6e00e00000 388K rw-s- fbarray_memseg-2048k-1-3 > 0x6e01000000 16777216K r---- [ anon ] > 0x7201000000 4K rw-s- fbarray_memseg-1048576k-0-0_203213 > ``` > > Fixes: 524e43c2ad9a ("mem: prepare memseg lists for multiprocess sync") > Cc: anatoly.burakov@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Dariusz Stojaczyk > --- > lib/librte_eal/common/eal_common_memory.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_eal/common/eal_common_memory.c > b/lib/librte_eal/common/eal_common_memory.c > index 53d9b51..6c47e11 100644 > --- a/lib/librte_eal/common/eal_common_memory.c > +++ b/lib/librte_eal/common/eal_common_memory.c > @@ -56,7 +56,8 @@ eal_get_virtual_area(void *requested_addr, size_t *size, > allow_shrink = (flags & EAL_VIRTUAL_AREA_ALLOW_SHRINK) > 0; > unmap = (flags & EAL_VIRTUAL_AREA_UNMAP) > 0; > > - if (next_baseaddr == NULL && internal_config.base_virtaddr != 0) > + if (next_baseaddr == NULL && internal_config.base_virtaddr != 0 && > + rte_eal_process_type() == RTE_PROC_PRIMARY) > next_baseaddr = (void *) internal_config.base_virtaddr; > > if (requested_addr == NULL && next_baseaddr) { > -- > 2.7.4 > >