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

atoly , dev at dpdk.org Subject:Re: [dpdk-dev] [PATCH] eal: map PCI memory resources after hugepages Of course you can take this job. Thanks you for your help.--From:?? Time:2014 Nov 10 (Mon) 18 : 01To:Burakov, Anatoly , dev at dpd

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

Of course you can take this job. Thanks you for your help.--From:?? Time:2014 Nov 10 (Mon) 18 : 01To:Burakov, Anatoly , dev at dpdk.org Cc:thomas.monjalon at 6wind.com Subject:Re: [PATCH] eal: map PCI memory resources after hugepage

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

It is a default value when the requested_addr isn't exist, not an overide. When the?pci_map_resource is called at the primary process, the?requested_addr is NULL. The default value will be provided by?default_map_addr. When the?pci_map_resource is called at the secondery process, the?requested_a

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

Hi Liang I don't think that overriding the value passed to pci_map_resource as argument is the way to go. While it results in less code, it looks weird, in my opinion at least, as I believe tracking the correctness of address being requested should be the responsibility of the caller, i.e. eith

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

A multiple process DPDK application must mmap hugepages and pci resources into same virtual addresses. By default the virtual addresses chosen by the primary process automatically when calling the mmap. But sometime the chosen virtual addresses isn't usable at secondary process. Such as the seco