[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