From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A657DA00E6 for ; Tue, 9 Jul 2019 12:26:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 74DEA1B997; Tue, 9 Jul 2019 12:26:23 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id AD3BC1B993; Tue, 9 Jul 2019 12:26:21 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 03:26:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,470,1557212400"; d="scan'208";a="165725771" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.82]) ([10.237.220.82]) by fmsmga008.fm.intel.com with ESMTP; 09 Jul 2019 03:26:19 -0700 To: Yasufumi Ogawa Cc: dev@dpdk.org, stable@dpdk.org References: <1555379952-23517-1-git-send-email-ogawa.yasufumi@lab.ntt.co.jp> <1555386203-23776-1-git-send-email-ogawa.yasufumi@lab.ntt.co.jp> <1555386203-23776-2-git-send-email-ogawa.yasufumi@lab.ntt.co.jp> <95821e91-33f1-686c-f4c1-8ce7a07646d4@gmail.com> From: "Burakov, Anatoly" Message-ID: <35081f35-1967-93cb-096c-08761ed2658d@intel.com> Date: Tue, 9 Jul 2019 11:26:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 1/1] fbarray: get fbarrays from containerized secondary X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 09-Jul-19 11:24 AM, Burakov, Anatoly wrote: > 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@lab.ntt.co.jp wrote: >>>> From: Yasufumi Ogawa >>>> >>>> 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@dpdk.org >>>> >>>> Signed-off-by: Yasufumi Ogawa >>>> --- >>> >>> 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 :) > ...however, i think a full 64-digit ID won't even fit into the fbarray filename, as i believe it's limited to something like 64 chars. Perhaps hostname would be enough after all... or we can increase fbarray name length - that would require ABI breakage but the ABI is already broken in this release, so it's OK i think. -- Thanks, Anatoly