Re: [dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[Nissim Nisimov <NissimN@Radware.com>]

Hi Anatoly,


Actually the use of --base-virtaddr will be valuable only when user know in advance the virtual addresses he wishes for huge pages in his application.

We found out that in some of the cases we don't know it in advance and propose a more generic solution which will solve the below issue without user interfering.

If user --base-virtaddr is not null (i.e user know the addresses he wants for the hugepages) our changes will be disabled and the code will act exactly as today without the patch.

Pls let me know if u have any more doubts.

Thx
Nissim

-----Original Message-----
From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com] 
Sent: Thursday, October 15, 2015 3:33 PM
To: Nissim Nisimov; dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

Hi

> Problem:
> In DPDK Primary/Secondary module we assume mapping same regions of 
> virtual memory addresses for Primary process and Secondary.
> An issue may occur when the Primary and secondary processes are not 
> symmetric in such way that the code is not the same (for example, 
> Primary process is a traffic distributer and secondary is a worker). 
> The result may be that specific virtual address region in the first 
> process won't be available in the second process.
> 
> Changes done at eal init:
> map all related rte configuration and uio sections close to the end of 
> huge pages memory (that mean rte_eal_memory_init() should be called 
> before
> rte_config_init() in primary process)
> According to our observations there will be more probability to 
> success when allocating rte_config and uio memzones after huge pages 
> sections (actually uio is already allocated after the huge pages area)

Not sure I understand the purpose of the patch. Doesn't --base-virtaddr flag solve your issues?

Thanks,
Anatoly