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 470F6A046B for ; Thu, 27 Jun 2019 13:46:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D69C4316B; Thu, 27 Jun 2019 13:46:56 +0200 (CEST) Received: from mail-vs1-f68.google.com (mail-vs1-f68.google.com [209.85.217.68]) by dpdk.org (Postfix) with ESMTP id 114AD2BE2 for ; Thu, 27 Jun 2019 13:46:54 +0200 (CEST) Received: by mail-vs1-f68.google.com with SMTP id j26so1386997vsn.10 for ; Thu, 27 Jun 2019 04:46:53 -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=RwnAG93fv0Mnrj6AlalYmlzI0TZMK4UxZB6GkDAYztM=; b=Ewn8IB6THv0qs03Dx4JlyhUVHFbWwwdXl0fQbazfqDiEBKQWlv+khoXn5QVdC++20N UC/Vms/8wvjh5KOUT6OeQrRqFEAxmFu1Ii0u6dtevDDfjyO0iGUAuY8u9vfA1XjCCe4a 0DZgvYfoayp5nLZla8Ky1Ln/kxs3heOIvWYUcNT++NUYA2G7DAVz6mzfzA3cApP/mZZd Vg+DZonSHYXHw1JvMDFLX0567+NzNe8aW4KgvcW5pD6hkFiZ4j21ix2P/ubamY2WNxnz 5iyGrjOt31CFRQkziQn3s8NBS1Q5QXEpYrN0hT6Ligj9+5hOKLaePp6BAAzvVWfmegj7 H+mw== X-Gm-Message-State: APjAAAVeZ8TgoJ1dJap65ahDTkDvMsUzowyvgBETEs0DLU/M6bC1I5k0 ZZ3mryDIN4U+sTxFudra/Xq/dsU5tRC/vGJUTD+Zkg== X-Google-Smtp-Source: APXvYqx83tOcp2+PiecTHN7uXAGNqn0syDnSVrzz4H7aPuTOBcrXVEiqXNy9ovnj5RZmnA2JYgc+Gs9a+BD8tE8kvcI= X-Received: by 2002:a67:da99:: with SMTP id w25mr2344208vsj.141.1561636013494; Thu, 27 Jun 2019 04:46:53 -0700 (PDT) MIME-Version: 1.0 References: <658a39af271ae33f9df20678da0655216646702c.1561635211.git.anatoly.burakov@intel.com> In-Reply-To: <658a39af271ae33f9df20678da0655216646702c.1561635211.git.anatoly.burakov@intel.com> From: David Marchand Date: Thu, 27 Jun 2019 13:46:42 +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] [PATCH v2 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 Thu, Jun 27, 2019 at 1:33 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 > --- > > Notes: > v2: > - Rebase on top of latest master > - Fix fd handling > - Fix mmap PROT flags on first map > > lib/librte_eal/freebsd/eal/eal.c | 49 ++++++++++++++++++++++++++++++-- > 1 file changed, 46 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_eal/freebsd/eal/eal.c > b/lib/librte_eal/freebsd/eal/eal.c > index 3e15af792..fac43b017 100644 > --- a/lib/librte_eal/freebsd/eal/eal.c > +++ b/lib/librte_eal/freebsd/eal/eal.c > @@ -288,10 +288,11 @@ rte_eal_config_attach(void) > } > > rte_mem_cfg_addr = mmap(NULL, sizeof(*rte_config.mem_config), > - PROT_READ | PROT_WRITE, MAP_SHARED, > mem_cfg_fd, 0); > - close(mem_cfg_fd); > - mem_cfg_fd = -1; > + PROT_READ, MAP_SHARED, mem_cfg_fd, 0); > + /* don't close the fd here, it will be closed on reattach */ > if (rte_mem_cfg_addr == MAP_FAILED) { > + close(mem_cfg_fd); > + mem_cfg_fd = -1; > RTE_LOG(ERR, EAL, "Cannot mmap memory for rte_config! > error %i (%s)\n", > errno, strerror(errno)); > return -1; > @@ -302,6 +303,46 @@ rte_eal_config_attach(void) > return 0; > } > > +/* reattach the shared config at exact memory location primary process > has it */ > +static int > +rte_eal_config_reattach(void) > +{ > + struct rte_mem_config *mem_config; > + void *rte_mem_cfg_addr; > + > + if (internal_config.no_shconf) > + return 0; > + > + /* save the address primary process has mapped shared config to */ > + rte_mem_cfg_addr = > + (void > *)(uintptr_t)rte_config.mem_config->mem_cfg_addr; > + > + /* unmap original config */ > + munmap(rte_config.mem_config, sizeof(struct rte_mem_config)); > + > + /* 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); > + close(mem_cfg_fd); > + mem_cfg_fd = -1; > + > + if (mem_config == MAP_FAILED) { > + RTE_LOG(ERR, EAL, "Cannot mmap memory for rte_config! > error %i (%s)\n", > + errno, strerror(errno)); > + return -1; > + } else if (mem_config != rte_mem_cfg_addr) { > + /* errno is stale, don't use */ > + RTE_LOG(ERR, EAL, "Cannot mmap memory for rte_config at > [%p], got [%p]\n", > + rte_mem_cfg_addr, mem_config); > + return -1; > + } > Ah, it looks better than this double if we have in linux eal.c :-) +1 + > + rte_config.mem_config = mem_config; > + > + return 0; > +} > + > /* Detect if we are a primary or a secondary process */ > enum rte_proc_type_t > eal_proc_type_detect(void) > @@ -342,6 +383,8 @@ rte_config_init(void) > if (rte_eal_config_attach() < 0) > return -1; > rte_eal_mcfg_wait_complete(rte_config.mem_config); > + if (rte_eal_config_reattach() < 0) > + return -1; > break; > case RTE_PROC_AUTO: > case RTE_PROC_INVALID: > -- > 2.17.1 > Reviewed-by: David Marchand Thanks! -- David Marchand