[dpdk-dev] [PATCH v8 1/1] fbarray: fix duplicated fbarray file in secondary

[Yasufumi Ogawa]

> 14/02/2020 16:08, David Marchand:
>> On Fri, Feb 14, 2020 at 8:46 AM Yasufumi Ogawa <yasufum.o at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Could I confirm that this patch is going to be merged in 20.02?
>>
>> Sorry, but I can't take this patch in 20.02.
>> It breaks compilation on FreeBSD.
>> http://mails.dpdk.org/archives/test-report/2019-November/109435.html
Sorry. I didn't find it. I'd see it.

>>
>>
>> I am still unconvinced on the need to change the size to something so
>> huge to accommodate with this new use case (secondary processes in
>> containers).
It is not so common actually, but serious issue for some NFV usecases. I 
remember, in a talk in the last DPDK summit, ZTE was also suffered from 
the same problem.

>> Why can't we truncate the container hostname so that it fits in 64 bytes?
It is just a possible maximum length of format of 
"fbarray_memseg-1048576k-0-0_PID_HOSTNAME", so I think it can be 
truncated if dropping some information.

>>
>>
>> Thomas, opinion?
> 
> If the use case is justified enough, I would prefer merging such change in
> 20.11 avoiding an ABI breakage in a core library, even if it is experimental.I understand, thanks.

Yasufumi