[dpdk-dev] [PATCH v2 1/1] fbarray: get fbarrays from containerized secondary
Burakov, Anatoly
anatoly.burakov at intel.com
Tue Jul 9 12:24:10 CEST 2019
On 09-Jul-19 11:22 AM, Yasufumi Ogawa wrote:
> Hi Anatoly,
>
> On 2019/07/05 17:53, Burakov, Anatoly wrote:
>> On 16-Apr-19 4:43 AM, ogawa.yasufumi at lab.ntt.co.jp wrote:
>>> From: Yasufumi Ogawa <ogawa.yasufumi at lab.ntt.co.jp>
>>>
>>> In secondary_msl_create_walk(), it creates a file for fbarrays with its
>>> PID for reserving unique name among secondary processes. However, it
>>> does not work if secondary is run as app container because each of
>>> containerized secondary has PID 1. To reserve unique name, use hostname
>>> instead of PID if the value is 1.
>>>
>>> Cc: stable at dpdk.org
>>>
>>> Signed-off-by: Yasufumi Ogawa <ogawa.yasufumi at lab.ntt.co.jp>
>>> ---
>>
>> I'm not too well versed in containers - is this hostname 1) always
>> set, and 2) always unique?
> For docker, 1) hostname is always set. 2) The hostname is decided as
> short form of container ID, so it might not be unique even though very
> low possibility.
>
> I found that we can get whole container ID in `/proc/self/cgroup` as
> discussed [1]. I think using hostname is reasonable way without running
> many secondary processes. However, it might be better to use 64 digits
> full container ID instead of 12 digits short ID if ensure uniqueness
> strongly. What do yo think?
>
> [1]
> https://forums.docker.com/t/get-a-containers-full-id-from-inside-of-itself/37237
>
I think it's better to err on the side of caution and guarantee better
uniqueness. This code will get into an LTS and will be used for years to
come :)
--
Thanks,
Anatoly
More information about the dev
mailing list