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 3E67FA046B for ; Wed, 26 Jun 2019 14:03:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EC31ADED; Wed, 26 Jun 2019 14:03:53 +0200 (CEST) Received: from mail-ua1-f65.google.com (mail-ua1-f65.google.com [209.85.222.65]) by dpdk.org (Postfix) with ESMTP id B140BDED for ; Wed, 26 Jun 2019 14:03:52 +0200 (CEST) Received: by mail-ua1-f65.google.com with SMTP id j2so657686uaq.5 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=rMZRbje6uZbU6VRqKh6znBh+G/Gv4j9pfqUVv92HdPO3PQPs2u9xOqYiin5l96pvdt BAHmZeFWVObs+fQ29s80C7QMKPCzADC9klDjP1gYt2WDwc2yQH+M2tFrC1fOecdWglDj wqXf1y6xvAhqb6FORAdJwgLSmz+bZ8oJ26U/tzfHu7veMqDvp5A10O4u9tNksf7jY/lg wSzW43h1/gFnpgws31MdNfHjzxvr0GtGMnxIZhZ+gvmMNMXPGoFTexGiJ5HbSbaBsjue X3/DYcs+lD5vfOSn1nw+cAkWyqYO5bfV7/lc4wkXWFczbi3IOxfqeGNb2xtDKihrEHvK zU1Q== X-Gm-Message-State: APjAAAXel+5mvTfJcZw425OUjwkel6tpgByFlSJ9tu6AvTyqPsXddsYf AR9LANwABU3Km3r+0ZmLBI9Zt8foCaeP+5VjBgMXpg== 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-stable] [PATCH 2/2] eal/freebsd: add config reattach 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: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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