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=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 1755EC43215 for ; Thu, 14 Nov 2019 12:28:14 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id A9E0920709 for ; Thu, 14 Nov 2019 12:28:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PPIpAkok" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9E0920709 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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 9D6E82BC7; Thu, 14 Nov 2019 13:28:12 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id E36D42BA8 for ; Thu, 14 Nov 2019 13:28:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573734490; 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=PPIpAkokww40uk/dPD52o6mSIteXGpHZf1vEeHqp3hpI2VX3Pk5VzTRIPdGQs8/boiCjSB M352HAj4HxvYPgjgRDi1ugh0gnE0Nt7KjEtRRYx7UIRZ99zgDr6f2wRFMMspBOLVnxrbG0 t0zNli7Fm9Iq9ysRFU2LispBKSx3+P8= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-140-ak5qyqOWMwGUxSlh7V0NPw-1; Thu, 14 Nov 2019 07:28:09 -0500 Received: by mail-vk1-f198.google.com with SMTP id n6so2548341vke.22 for ; Thu, 14 Nov 2019 04:28:09 -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=HtiIMP2OgktuwGaFsinioZS8PGMh4XUMts7d4GKHVFChISCcDCBuRTcC3KkL6eI5Yt 6TNASbduJiq7QMhk+c4sveKsxmQSlmAsc67XiKahOrhHaxNoP9/wQF8GErHFm4MOwFvS dM/NBZc6G3gCH2e/Jnw+xvJ5nJ4OnV+shmHq5qijxJCm8sE7u9cnt9Q1V76Xk1Y0/bNf /fKkaDZtIQhOlx3vCjWmYCPJBwlrlOQncw0ufN2TRphmmByNImpaOPbrgtiS8BhLRJY5 57nXSm1qdk6nk5/TlIFsIwNyHBnHfOh3OrwmI9PmI6IBVTUrSMqYPKE7P2K8Y8o/vzFr pkuQ== X-Gm-Message-State: APjAAAW4WOMgQGTA16Xuo/twpbnkm7QfVfW2HPIqe2X6VaSgx7Wg7wzl i8nRiPxagHGg2oEqZvZACnmrN4kdAgxOjD97vwuGSFus+lUOyOzs56KHqgDzqDaMqURnvx7QNXt vWi9JLuKR1TQLXp4K8aM= X-Received: by 2002:a67:f3c7:: with SMTP id j7mr5256877vsn.141.1573734488364; 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: ak5qyqOWMwGUxSlh7V0NPw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v7 1/1] fbarray: fix duplicated fbarray file in 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 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