DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Bruce Richardson <bruce.richardson@intel.com>,
	dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 2/2] eal/freebsd: add config reattach
Date: Wed, 26 Jun 2019 13:49:35 +0100	[thread overview]
Message-ID: <d4a155c4-6574-0007-dd10-c58d3f4d815d@intel.com> (raw)
In-Reply-To: <CAJFAV8zFshKey6dbiW=LTN59H53bv_=WKjCVNd==0r4_jaQPKw@mail.gmail.com>

On 26-Jun-19 1:03 PM, David Marchand wrote:
> On Tue, Jun 25, 2019 at 5:51 PM Anatoly Burakov <anatoly.burakov@intel.com>
> 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 <anatoly.burakov@intel.com>
>> ---
>>   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.

Nope, tried it - doesn't fit.

> 
> +
>> +       /* unmap original config */
>> +       munmap(rte_config.mem_config, sizeof(struct rte_mem_config));
>>
> 
> Hum, the previous mapping is PROT_WRITE while unneeded, right?

Yes, good catch.

> 
> 
> +
>> +       /* 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.

Hmm, wonder why it didn't. I'll investigate and fix if necessary.

> 
> 
> +       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?
> 

No real reason. Implementing that is probably out of scope for this 
patchset though.

-- 
Thanks,
Anatoly

  parent reply	other threads:[~2019-06-26 12:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25 15:50 [dpdk-dev] [PATCH 1/2] eal/freebsd: fix missing write to internal config Anatoly Burakov
2019-06-25 15:50 ` [dpdk-dev] [PATCH 2/2] eal/freebsd: add config reattach Anatoly Burakov
2019-06-26 12:03   ` [dpdk-dev] [dpdk-stable] " David Marchand
2019-06-26 12:21     ` David Marchand
2019-06-26 12:50       ` Burakov, Anatoly
2019-06-26 12:49     ` Burakov, Anatoly [this message]
2019-06-26 12:03 ` [dpdk-dev] [dpdk-stable] [PATCH 1/2] eal/freebsd: fix missing write to internal config David Marchand
2019-06-27 11:33 ` [dpdk-dev] [PATCH v2 " Anatoly Burakov
2019-06-27 11:33 ` [dpdk-dev] [PATCH v2 2/2] eal/freebsd: add config reattach Anatoly Burakov
2019-06-27 11:46   ` David Marchand
2019-07-01 16:02     ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d4a155c4-6574-0007-dd10-c58d3f4d815d@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).