[dpdk-dev] [PATCH v8] eal: map PCI memory resources after hugepages

2014-11-25 Thread Thomas Monjalon
> > Multi-process DPDK application must mmap hugepages and PCI resources > > into the same virtual address space. By default the virtual addresses > > are chosen by the primary process automatically when calling the mmap. > > But sometimes the chosen virtual addresses aren't usable in secondary >

[dpdk-dev] [PATCH v8] eal: map PCI memory resources after hugepages

2014-11-13 Thread Bruce Richardson
On Tue, Nov 11, 2014 at 10:09:25AM +, Anatoly Burakov wrote: > Multi-process DPDK application must mmap hugepages and PCI resources > into the same virtual address space. By default the virtual addresses > are chosen by the primary process automatically when calling the mmap. > But sometimes

[dpdk-dev] [PATCH v8] eal: map PCI memory resources after hugepages

2014-11-13 Thread Burakov, Anatoly
> Why has this check been removed from here. I assume it is replaced by a > new check in secondary processes that I see added below, but perhaps you > could explain the reason for the change? Sure. The reason behind that change is that we can't expect that we will get a mapping at exact same

[dpdk-dev] [PATCH v8] eal: map PCI memory resources after hugepages

2014-11-13 Thread Bruce Richardson
Thanks, > Anatoly > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Anatoly Burakov > Sent: Tuesday, November 11, 2014 10:09 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v8] eal: map PCI memory resources after hugepages > > Multi

[dpdk-dev] [PATCH v8] eal: map PCI memory resources after hugepages

2014-11-11 Thread Anatoly Burakov
Multi-process DPDK application must mmap hugepages and PCI resources into the same virtual address space. By default the virtual addresses are chosen by the primary process automatically when calling the mmap. But sometimes the chosen virtual addresses aren't usable in secondary process - for