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 006DFA046B for ; Wed, 26 Jun 2019 14:22:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6CAD42956; Wed, 26 Jun 2019 14:22:10 +0200 (CEST) Received: from mail-ua1-f68.google.com (mail-ua1-f68.google.com [209.85.222.68]) by dpdk.org (Postfix) with ESMTP id A7F4F271 for ; Wed, 26 Jun 2019 14:22:09 +0200 (CEST) Received: by mail-ua1-f68.google.com with SMTP id j21so681504uap.2 for ; Wed, 26 Jun 2019 05:22:09 -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=n6Ishw1O6fpvjjz7dnRz/cFMBVVPG6edCFfxKd427TI=; b=t+rb4Bh507fAIczlAfRnOsJ9YZXeUb40K907fqxw6NYRgCBSsrDa7lH28xJ582wcv5 RmQyxjYMCz09DaL0SJ2UP+RcbCs1/U25RS1MSx4zF+1mlYYtuA/nQ5qs+Wsm361bjske +JekHdmfXYdsXROHquCT6yHAQAPSeoyUcHhRBWvXNPyvBRMA+PFuqN6JzK5KUHu7wFQS n0pDN1KISHwJAn9RnF71XWAKE9K6uinAyOib6klo5fK5DZ9qO5EYeVh++nSEtH12dzr0 pGiYQXgXK+Ua2GWupM+NbDfGENkiFqXWm30KCsQyW3RbBC1XdqRNz/ky/Ia3c6E99mRd f16Q== X-Gm-Message-State: APjAAAX504d+WhDGnO1r2gwEO8+VDKDGxG+j36Ac6Xrnhu/6qHHuC3I3 xA42bd8eJNeK+VC5MJFMpA40wOVITaZFq9XJF5BTqA== X-Google-Smtp-Source: APXvYqzqQkoppSa9i6F/p0GwgEfawit2vG41dUfKnIK7Q4LpslL8n2coBD+cSsv9A2cWPwKdheCiLiShAfxClO5Yq+0= X-Received: by 2002:ab0:b99:: with SMTP id c25mr2365113uak.53.1561551728953; Wed, 26 Jun 2019 05:22:08 -0700 (PDT) MIME-Version: 1.0 References: <0fdd08d79feb1b60c304a1194d14282238cb679e.1561477829.git.anatoly.burakov@intel.com> In-Reply-To: From: David Marchand Date: Wed, 26 Jun 2019 14:21:57 +0200 Message-ID: To: Anatoly Burakov Cc: dev , Bruce Richardson , dpdk stable , Arnon Warshavsky 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 Wed, Jun 26, 2019 at 2:03 PM David Marchand wrote: > > > 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? > Not sure you noticed, but Arnon also had sent a patch touching the config mapping parts. http://patchwork.dpdk.org/patch/54583/ -- David Marchand