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

[han.li1 at zte.com.cn]

it seems your patch is later then mine?
you rejected mine patch and then committed yours?
I can't understand....




------------------origin------------------
from：Burakov,Anatoly <anatoly.burakov at intel.com>
to：David Marchand <david.marchand at redhat.com>;
copy：han.li1;Thomas Monjalon <thomas at monjalon.net>;dev <dev at dpdk.org>;
date ：2019/10/24 20:39
title ：Re: [dpdk-dev] [PATCH v3] lib/librte_eal/linuxapp: fix runtime configmmap issue
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