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=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 6D33BCA9EC5 for ; Wed, 30 Oct 2019 13:42:25 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id DA08A20578 for ; Wed, 30 Oct 2019 13:42:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gic8x8nV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA08A20578 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 CCDE41BFBD; Wed, 30 Oct 2019 14:42:22 +0100 (CET) Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by dpdk.org (Postfix) with ESMTP id DC7D61BFA6; Wed, 30 Oct 2019 14:42:20 +0100 (CET) Received: by mail-pg1-f193.google.com with SMTP id 15so1513580pgt.7; Wed, 30 Oct 2019 06:42:20 -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=NCV4AMUTcYnGfx0PgD7/mYS6cnFNcIPG2w9Yb6S3E1w=; b=gic8x8nVezL5t5kuGw+G6wnILd6Angn0HUbicnDbFDz1kkz8dNum1LbJW9p917ZBpF D+SwqPGIGC+WGoWRZmD6HqrYj60oMeq4vtG7AKVWvImQDlrPSjHR6zLj9s9bRWlMi0lY wxjX9EJTqJz94OzONZORzWp1dRquYnPYcdRZgATozGNFbaNibUAAPNUPzgkoQHKzSZwG i7tYwNC5QNzh7MsQlK26MjgEv3hZn7muvo9H64QDcqtog+rw4Lyj2BipyPrRoTyMh1VB rfDU+5i9LCsi8VFxRAK5/gOFh1g2eLuTWAfJw/BaQezEv0VY7Jr+JnrwxCeO5o/T4hVe Q1Ug== 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=NCV4AMUTcYnGfx0PgD7/mYS6cnFNcIPG2w9Yb6S3E1w=; b=lxZgf7BeT1XlrNroOV3rnNGTQF5o5h14pt8CYkzsuVn9uLgXH2fENfnBgiWWdqxBr1 GVc+sf4a8s/T6odSHfQ34ZJ9kfoBsdwHUfSCClxLSGdryWXZ1QoHfuCJM7hjGgH4RlLX ZdwJByc9Fpdcj+/VOpmthSGXJGsl8dpJrR5hxLs5PTf+IymsCarGY60A+VB529JBMbvQ +uhlKjDmjtxFMuSPzgtCpBc7e5E5sfvYlt1+4sKnTguafslRjsoUFQScCytzXawIFDgg jOkuK0L+1L66dcwmJ8mimxPF6NOdS1deilVaawW7Z6FEC27uuFA3AnuuzyyRaVfGPF1i WLow== X-Gm-Message-State: APjAAAX7BYo5ry0YZR0OcbBaEUIuQUe8uzjoLsLgtSmqqQCVlLlCr0VR xwD0SB5K28k0j56qq8PtaK8= X-Google-Smtp-Source: APXvYqwqPwQK88Fmsw77urhe7pPMbiVezJXZDEvHEphvJhqlCZt+mTCCfTwH6nVAzpK4dULVeFzRng== X-Received: by 2002:a63:fe44:: with SMTP id x4mr34105432pgj.118.1572442939931; Wed, 30 Oct 2019 06:42:19 -0700 (PDT) Received: from mugwort.local ([2400:4050:c8c2:de00:447f:d390:36f3:7529]) by smtp.gmail.com with ESMTPSA id s12sm3826786pgf.36.2019.10.30.06.42.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 06:42:19 -0700 (PDT) To: "Ananyev, Konstantin" , "Burakov, Anatoly" , "david.marchand@redhat.com" Cc: "dev@dpdk.org" , "stable@dpdk.org" , Yasufumi Ogawa References: <20190724082031.45546-1-yasufum.o@gmail.com> <20191028080745.43425-1-yasufum.o@gmail.com> <20191028080745.43425-2-yasufum.o@gmail.com> <2601191342CEEE43887BDE71AB97725801A8C71D04@IRSMSX104.ger.corp.intel.com> From: Yasufumi Ogawa Message-ID: <591ba077-5e0c-340d-4bd4-a45e80e90f53@gmail.com> Date: Wed, 30 Oct 2019 22:42:16 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C71D04@IRSMSX104.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 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 2019/10/29 21:03, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: dev On Behalf Of yasufum.o@gmail.com >> Sent: Monday, October 28, 2019 8:08 AM >> To: Burakov, Anatoly ; david.marchand@redhat.com >> Cc: dev@dpdk.org; stable@dpdk.org; yasufum.o@gmail.com; Yasufumi Ogawa >> Subject: [dpdk-dev] [PATCH v5 1/1] fbarray: fix duplicated fbarray file in secondary >> >> 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 several secondaries run as app containers because each >> of containerized secondary has PID 1, and failed to reserve unique name >> other than first one. To reserve unique name in each of containers, use >> hostname instead of PID only if PID is 1. >> >> Cc: stable@dpdk.org >> >> Signed-off-by: Yasufumi Ogawa >> --- >> lib/librte_eal/linux/eal/eal_memalloc.c | 15 +++++++++++++-- >> 1 file changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c >> index af6d0d023..699079791 100644 >> --- a/lib/librte_eal/linux/eal/eal_memalloc.c >> +++ b/lib/librte_eal/linux/eal/eal_memalloc.c >> @@ -1365,6 +1365,7 @@ 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 proc_id[HOST_NAME_MAX] = { 0 }; >> >> if (msl->external) >> return 0; >> @@ -1374,8 +1375,18 @@ secondary_msl_create_walk(const struct rte_memseg_list *msl, >> local_msl = &local_memsegs[msl_idx]; >> >> /* create distinct fbarrays for each secondary */ >> - snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i", >> - primary_msl->memseg_arr.name, getpid()); >> + /* If run secondary in a container, the name of fbarray file should >> + * not be decided with pid because getpid() always returns 1. > > > I wonder why is that? > What will prevent user to do something like: > docker run -it --cpuset-cpus=7-8 -v /local/kananye1:/local/kananye1 ubuntu-dpdk-local:latest /bin/bash > And then start dpdk app manually within the container? Hi Konstantin, Thank you for your comment. My concern is running secondary as app container. In current implementation, the name of fbarray file is decided by using PID and it must be overlapped with other process because assigning PID is started from 1 in each of app container. This patch is to fix the issue. I think it is doable running app from bash for testing, but not acceptable for a realistic usecase in which user manages several app containers. Regards, Yasufumi > >> + * In docker, hostname is assigned as a short form of full container >> + * ID. So use hostname as unique ID among containers instead. >> + */ >> + if (getpid() == 1) >> + gethostname(proc_id, HOST_NAME_MAX); >> + else >> + sprintf(proc_id, "%d", (int)getpid()); >> + >> + snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s", >> + primary_msl->memseg_arr.name, proc_id); >> >> ret = rte_fbarray_init(&local_msl->memseg_arr, name, >> primary_msl->memseg_arr.len, >> -- >> 2.17.1 >