From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0B55C74A4B for ; Thu, 11 Jul 2019 09:38:02 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 50AAC20872 for ; Thu, 11 Jul 2019 09:38:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aON81Uzz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50AAC20872 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 811051B94E; Thu, 11 Jul 2019 11:38:01 +0200 (CEST) Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by dpdk.org (Postfix) with ESMTP id 9680F4C8E; Thu, 11 Jul 2019 11:37:59 +0200 (CEST) Received: by mail-pf1-f193.google.com with SMTP id p184so2485441pfp.7; Thu, 11 Jul 2019 02:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TKqEq9eicae0fSCT8vU1HrNA4+QdK/JXdfk408WN9hQ=; b=aON81Uzz5KQgfeiOHSTZyjnhiQVDrRCdhkuddINt500HmRFcvmXd50C0Swf1mC4giq rgTOpRqmK1QtTFRfDI3cD3vdR2+sNmTOj0AaOiN8Kxi8uQMKVm7OeDi7VVcltC6BfVOV PMuB+XqRkZ+yPhFeM2+4Po0Boq8YvSsmBIYR1eYKNOg6XDERUYSqsqKkDpa3gYadR8jO 4hhT8ravkCl7UlgUFt+irpZqw2XkV/EP/XIDhUoI5oCOdD0OvgThdL/LqI7kw5QHFyo/ zCqwBn5UZRCWoOvYdjDVQBHt3Ti0ScYym0hyu565P0DfMqPrJy9DN4UvFDkoMhUe+7Pz xq+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TKqEq9eicae0fSCT8vU1HrNA4+QdK/JXdfk408WN9hQ=; b=HVSttVEpSKqAUcGgCZ0TWgkzpwXhS32h4jTqxzEFPbfac9KK+P8O9HBmc/JsMA9hmG XbJpW4YKU9w2Wy97T19fmrHqPCo0574/iha9niw94+wT1lkCQJSUuUj7Z8n/aLsH3Uim EZ2lEOmPq+aRSd1IsaGReRIOA666vUVwUjrqK5+mq9T+9Hc3Ol6WjdDKdqgtAjb6CPCM wYwW2gyuHfE89Nij9Uge4BCsgr2TTgOBvXBCT+cmbXBoqmI8OpBZ4WFIUkWTQTl2XR7s I7aNY8hw2gCQuQClk+utxnpAqF5HeUiRMvdw7lGHSEhMh+l7xYrgak4u/UlSbd99906V gXzQ== X-Gm-Message-State: APjAAAV0HnbPYLNvYeWQFQWq1S13yWlg/6yui/cxZG+EEbcN2ela/H6K uPRKpJza4BvRYRg/CIDgqobrzUYK X-Google-Smtp-Source: APXvYqz7K3DruF4UdG+i1TJ4L7KHX3fmzZGJEzxE1RfDH/Cf1J1qkeEQ6dtlBwSIXEPLG1hgFaxW/w== X-Received: by 2002:a63:6110:: with SMTP id v16mr45236pgb.60.1562837878697; Thu, 11 Jul 2019 02:37:58 -0700 (PDT) Received: from mugwort.local ([192.47.164.146]) by smtp.gmail.com with ESMTPSA id b37sm11558692pjc.15.2019.07.11.02.37.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 02:37:57 -0700 (PDT) To: "Burakov, Anatoly" 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> <35081f35-1967-93cb-096c-08761ed2658d@intel.com> From: Yasufumi Ogawa Message-ID: <4e4ad489-7b1e-9406-4871-4a3ae7f318ee@gmail.com> Date: Thu, 11 Jul 2019 18:37:55 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <35081f35-1967-93cb-096c-08761ed2658d@intel.com> 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 2019/07/09 19:26, Burakov, Anatoly wrote: > 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. OK. >> Wouldn't an error in fscanf() leak the file handle? I think you need to fclose() before checking the result. > I would like to fix it. I would like send v3 patch for fixing for fclose(). Thanks, Yasufumi