[dpdk-dev] [PATCH v3] lib/librte_eal/linuxapp: fix runtime config mmap issue

[Burakov, Anatoly]

On 24-Oct-19 1:22 PM, Burakov, Anatoly wrote:
> On 24-Oct-19 12:23 PM, David Marchand wrote:
>> On Thu, Oct 24, 2019 at 1:14 PM Burakov, Anatoly
>> <anatoly.burakov at intel.com> wrote:
>>>
>>> On 24-Oct-19 8:37 AM, David Marchand wrote:
>>>> On Wed, Oct 23, 2019 at 7:47 PM Burakov, Anatoly
>>>> <anatoly.burakov at intel.com> wrote:
>>>>>
>>>>> On 23-Oct-19 11:42 AM, Li Han wrote:
>>>>>> In rte_eal_config_reattach(),the secondary mmap may fail
>>>>>> due to the rte_mem_cfg_addr already be used by others.do
>>>>>> the change just as the rte_fbarray_init() do.if no
>>>>>> base_virtaddr,use the default 0x100000000.
>>>>>>
>>>>>> v2/v3:
>>>>>> -fix code style issues
>>>>>>
>>>>>> Signed-off-by: Li Han <han.li1 at zte.com.cn>
>>>>>> ---
>>>>>
>>>>> Nack. There's a reason why we map it at the same address, and it's to
>>>>> have all pointers working across processes. Remapping it at a 
>>>>> different
>>>>> address has potential to break things.
>>>>
>>>> Marked as rejected.
>>>> Thanks.
>>>>
>>>
>>> Hi David,
>>>
>>> My apologies, I've misinterpreted the intent of the patch. I am
>>> rescinding my NACK.
>>
>> Ok, I will put it back in my queue.
>> No conflict with the work on
>> http://patchwork.dpdk.org/project/dpdk/list/?series=5854 ?
>> There was a comment by Stephen, btw.
>>
> 
> Oh, i forgot about that patchset...
> 
> Yes, it seems to be doing the same thing, but in a more general way 
> (because i was actually fixing an issue on FreeBSD...). Let me get back 
> to you on this.
> 

Yes, that patch is a superset of this one, so this can be discarded, i 
think. Apologies for the back and forth.

-- 
Thanks,
Anatoly