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 1F002A04C3 for ; Thu, 14 Nov 2019 13:28:15 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0ADBE2C08; Thu, 14 Nov 2019 13:28:15 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 73B652BA8 for ; Thu, 14 Nov 2019 13:28:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573734492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+/KEVHHbDxVOnNrL9gMajeThbW+YgDqaE9W+aJf7kS4=; b=GC+PuudMIc/TGwdwa9WCJKJ9nVK95C0uXb4pK+lSiTXgu6aWofrumu9JJmYqGjoJMR7bnI PNG2q3Ki4rMjwIANOe8RiKCFzSiLvg3naif+ffWYLWj71mIbLLGXibpa72JTFvVxUUHsok GFkNzBOrCoFJJ2YAXa1h3wIM0re4Y6Q= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-385-pVgYLBQ9PmKvoIpOqe0N6w-1; Thu, 14 Nov 2019 07:28:09 -0500 Received: by mail-vk1-f200.google.com with SMTP id p3so651312vkd.3 for ; Thu, 14 Nov 2019 04:28:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LLsN3SpCMNah3Ol/KEr1h7o4aX7pUxjWc/mu16h8pKI=; b=EoAMsb1aiVkB9jSSqzD0GGv75XuSVhPqtu64EcPyTmzNXBaX5NVWJ5sXjpJrcfbIkW b5kuxwq1ikj+2l11pcgnSVVsi6IzPoYsv+Hg7RmAPQb0oMpFqiwL0t9lr/MU6w0hhnzR /7rGZxXl5+TLY46HKAgTDiuTuEqZA42cZgy2/ysII81mzkVJGfmw0Q1IqepEdQk42zJE NLtDJfvBbPuG+G1MQXZUmya4KJJ5CzKy3LFPI+dKEUXrTJYyu/Vhej75a4t+XU4Lyiwz vLRYp+nZDz25BzjuvrmQ8V2M3wbJ5H7jKWb2yXIzN6MZuHa6zc9CnWvpeSsx+H/9Vktw txnA== X-Gm-Message-State: APjAAAVtVJbBPzS37tqJ2cH/eKBYuuE+rW/fjxPuwBHREjnGoCC7k2Ff 9rT53TI7ZA0IApxCfhRWRjKPR4c8X2QJW84Nbx/PHMywQGVDARXHzA+K1qBBowzDloXCNtaA8j7 ftIiGF5/ijXx/747SpB/BDlY= X-Received: by 2002:a67:f3c7:: with SMTP id j7mr5256880vsn.141.1573734488370; Thu, 14 Nov 2019 04:28:08 -0800 (PST) X-Google-Smtp-Source: APXvYqx+Ixcw3qYSBCjEwyv7O7CCAkOAJAWb/B6PeE5FCI8l/l9p2nuMiyonVVKtRC+A83yDDvKlJHagh7p/RGdPaDQ= X-Received: by 2002:a67:f3c7:: with SMTP id j7mr5256856vsn.141.1573734487943; Thu, 14 Nov 2019 04:28:07 -0800 (PST) MIME-Version: 1.0 References: <20190724082031.45546-1-yasufum.o@gmail.com> <20191113214346.33749-1-yasufum.o@gmail.com> <20191113214346.33749-2-yasufum.o@gmail.com> <6a6d7228-f22b-9ba5-c288-1701b738b7c4@intel.com> <61dd1730-3c80-da57-126d-84596b23ff31@gmail.com> In-Reply-To: <61dd1730-3c80-da57-126d-84596b23ff31@gmail.com> From: David Marchand Date: Thu, 14 Nov 2019 13:27:56 +0100 Message-ID: To: Yasufumi Ogawa Cc: "Burakov, Anatoly" , "Ananyev, Konstantin" , dev , dpdk stable , Yasufumi Ogawa X-MC-Unique: pVgYLBQ9PmKvoIpOqe0N6w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [PATCH v7 1/1] fbarray: fix duplicated fbarray file in secondary X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Thu, Nov 14, 2019 at 12:42 PM Yasufumi Ogawa wrote= : > > On 2019/11/14 2:01, Burakov, Anatoly wrote: > > On 13-Nov-19 9:43 PM, yasufum.o@gmail.com wrote: > >> From: Yasufumi Ogawa > >> > >> In secondary_msl_create_walk(), it creates a file for fbarrays with it= s > >> PID for reserving unique name among secondary processes. However, it > >> does not work if several secondaries run as app containers because eac= h > >> of containerized secondary has PID 1, and failed to reserve unique nam= e > >> other than first one. To reserve unique name in each of containers, us= e > >> hostname in addition to PID. > >> > >> Cc: stable@dpdk.org > >> > >> Signed-off-by: Yasufumi Ogawa > >> --- > >> lib/librte_eal/linux/eal/eal_memalloc.c | 16 +++++++++++++--- > >> 1 file changed, 13 insertions(+), 3 deletions(-) > >> > >> diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c > >> b/lib/librte_eal/linux/eal/eal_memalloc.c > >> index af6d0d023..11de6d4d6 100644 > >> --- a/lib/librte_eal/linux/eal/eal_memalloc.c > >> +++ b/lib/librte_eal/linux/eal/eal_memalloc.c > >> @@ -1365,6 +1365,12 @@ secondary_msl_create_walk(const struct > >> rte_memseg_list *msl, > >> struct rte_memseg_list *primary_msl, *local_msl; > >> char name[PATH_MAX]; > >> int msl_idx, ret; > >> + char hostname[HOST_NAME_MAX+1] =3D { 0 }; > >> + /* filename of secondary's fbarray is defined such as > >> + * "fbarray_memseg-1048576k-0-0_PID_HOSTNAME" and length of PID > >> + * can be 7 digits maximumly. > >> + */ > >> + int fbarray_sec_name_len =3D 32 + 7 + 1 + HOST_NAME_MAX + 1; > > > > What does 32 stand for? Maybe #define both 32 and 7 values? > Hi Anatoly, > > Thank you for your comments! If my understanding is correct, the prefix > "fbarray_memseg-1048576k-0-0_" is 28 digits and it could be larger if > using the size of hugepage or the number of NUMA nodes are larger > possibly. However, I think 32 digits is still enough. > > > Maybe #define both 32 and 7 values? > Yes. I think it should be better to use #define if this values are > referred several times. We can truncate to RTE_FBARRAY_NAME_LEN in all cases. And iiuc, rte_fbarray_init will refuse any longer name anyway. --=20 David Marchand