From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A9868A046B for ; Wed, 26 Jun 2019 14:03:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2E07425D9; Wed, 26 Jun 2019 14:03:54 +0200 (CEST) Received: from mail-ua1-f66.google.com (mail-ua1-f66.google.com [209.85.222.66]) by dpdk.org (Postfix) with ESMTP id B3D671E25 for ; Wed, 26 Jun 2019 14:03:52 +0200 (CEST) Received: by mail-ua1-f66.google.com with SMTP id o2so647688uae.10 for ; Wed, 26 Jun 2019 05:03:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jJs6Jb/5YbtOcGqnklObMs4wrS8oIBiinWX5XiFPwyE=; b=g7TfBf056iPrfI4Wg5VfG6pN9vGN0Jw2L1yMPrzUIlqUQQQyFqLp75xdaZWZjvgFuW oZV53w/Ce/3T/3PLm/0BkyCvOd5nB0gT/WhO2xhG6WZVTshyUbtuXW/qVo3XCP8ZoXCg 81zskNfpcBmayKYJZqQebn59amXTrBK8Mm9iwmFVKfap3PdV9OC/0Can1oREWMnJhwQ8 GRFzx6B6WYyQJ1kTzPHCEFK2sitvuR0HBVbJGTky2qu+WaJhECAz+iVpsJRPvLhKuAPD yPzqNhJesfs1Cz0oyLxsZpISU62/EzEHw8aBeNDBdTLSwrizM00uLK5MEUMf5MiBs0pl 0AWw== X-Gm-Message-State: APjAAAWd20s0UQWRFXdKp806pl77TwucVOTg5Vsx4NUaE4h3OFQo8A2C Dh/agASHn4YzSVEptbt+bPocTO29tfD167YOn8d6fQ== X-Google-Smtp-Source: APXvYqxDmoP/jGzJaH5NIJlfoMCjkY3BcZyRJrPU8oWIgAtFZCxuZsgq1iIoSmZx9zhDcChrPO0akrKV0dd4DdU927M= X-Received: by 2002:ab0:6198:: with SMTP id h24mr2294340uan.41.1561550631809; Wed, 26 Jun 2019 05:03:51 -0700 (PDT) MIME-Version: 1.0 References: <0fdd08d79feb1b60c304a1194d14282238cb679e.1561477829.git.anatoly.burakov@intel.com> In-Reply-To: <0fdd08d79feb1b60c304a1194d14282238cb679e.1561477829.git.anatoly.burakov@intel.com> From: David Marchand Date: Wed, 26 Jun 2019 14:03:40 +0200 Message-ID: To: Anatoly Burakov Cc: dev , Bruce Richardson , dpdk stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 2/2] eal/freebsd: add config reattach 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Jun 25, 2019 at 5:51 PM Anatoly Burakov wrote: > Linux EAL will attach the shared config at an arbitrary address, > find out where the shared config is mapped in the primary, and > then will reattach it at that exact address. > > FreeBSD version doesn't seem to go for that extra reattach step, > which makes one wonder how did it ever work in the first place. > > Fix the FreeBSD init to also reattach shared config to the exact > same place the primary process has it. > > Fixes: 764bf26873b9 ("add FreeBSD support") > Cc: bruce.richardson@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Anatoly Burakov > --- > lib/librte_eal/freebsd/eal/eal.c | 36 ++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > > diff --git a/lib/librte_eal/freebsd/eal/eal.c > b/lib/librte_eal/freebsd/eal/eal.c > index 8c399c799..ce7a5f91d 100644 > --- a/lib/librte_eal/freebsd/eal/eal.c > +++ b/lib/librte_eal/freebsd/eal/eal.c > @@ -280,6 +280,41 @@ rte_eal_config_attach(void) > rte_config.mem_config = rte_mem_cfg_addr; > } > > +/* reattach the shared config at exact memory location primary process > has it */ > +static void > +rte_eal_config_reattach(void) > +{ > + struct rte_mem_config *mem_config; > + void *rte_mem_cfg_addr; > + > + if (internal_config.no_shconf) > + return; > + > + /* save the address primary process has mapped shared config to */ > + rte_mem_cfg_addr = > + (void > *)(uintptr_t)rte_config.mem_config->mem_cfg_addr; > It should be within the 80 columns limit on a single line. + > + /* unmap original config */ > + munmap(rte_config.mem_config, sizeof(struct rte_mem_config)); > Hum, the previous mapping is PROT_WRITE while unneeded, right? + > + /* remap the config at proper address */ > + mem_config = (struct rte_mem_config *) mmap(rte_mem_cfg_addr, > + sizeof(*mem_config), PROT_READ | PROT_WRITE, > MAP_SHARED, > + mem_cfg_fd, 0); > mem_cfg_fd should have been closed in rte_eal_config_attach(). So it should fail here. + if (mem_config == MAP_FAILED || mem_config != rte_mem_cfg_addr) { > + if (mem_config != MAP_FAILED) > + /* errno is stale, don't use */ > + rte_panic("Cannot mmap memory for rte_config at > [%p], got [%p]\n", > + rte_mem_cfg_addr, mem_config); > + else > + rte_panic("Cannot mmap memory for rte_config! > error %i (%s)\n", > + errno, strerror(errno)); > + } > + close(mem_cfg_fd); > + > + rte_config.mem_config = mem_config; > +} > + > /* Detect if we are a primary or a secondary process */ > enum rte_proc_type_t > eal_proc_type_detect(void) > @@ -318,6 +353,7 @@ rte_config_init(void) > case RTE_PROC_SECONDARY: > rte_eal_config_attach(); > rte_eal_mcfg_wait_complete(rte_config.mem_config); > + rte_eal_config_reattach(); > break; > case RTE_PROC_AUTO: > case RTE_PROC_INVALID: > -- > 2.17.1 > Is there a reason why FreeBSD EAL does not support the virtaddr hint like for Linux EAL? -- David Marchand