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 0BD51A00BE for ; Tue, 29 Oct 2019 13:03:08 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D308A1BECA; Tue, 29 Oct 2019 13:03:07 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id D63E51BE95; Tue, 29 Oct 2019 13:03:03 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2019 05:03:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,243,1569308400"; d="scan'208";a="205450593" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by FMSMGA003.fm.intel.com with ESMTP; 29 Oct 2019 05:03:01 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by IRSMSX153.ger.corp.intel.com ([169.254.9.119]) with mapi id 14.03.0439.000; Tue, 29 Oct 2019 12:03:01 +0000 From: "Ananyev, Konstantin" To: "yasufum.o@gmail.com" , "Burakov, Anatoly" , "david.marchand@redhat.com" CC: "dev@dpdk.org" , "stable@dpdk.org" , Yasufumi Ogawa Thread-Topic: [dpdk-dev] [PATCH v5 1/1] fbarray: fix duplicated fbarray file in secondary Thread-Index: AQHVjWboyzo5DJvfSke19jGIo5rl4adxhdSg Date: Tue, 29 Oct 2019 12:03:00 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801A8C71D04@IRSMSX104.ger.corp.intel.com> References: <20190724082031.45546-1-yasufum.o@gmail.com> <20191028080745.43425-1-yasufum.o@gmail.com> <20191028080745.43425-2-yasufum.o@gmail.com> In-Reply-To: <20191028080745.43425-2-yasufum.o@gmail.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmI4NjM2YTMtMDI1My00NDFhLWFiZjQtOGQxMmFhMTMyM2I2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoibVVuOUZpMWNUaVVsOXpTc3JsenN3QW40dmd5OG1cLzF0YldmYXhGMlZnM1graVVOS2oyZWpcL0xcL3B1YVJzcm55ayJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v5 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" > -----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.c= om > 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 i= n secondary >=20 > From: Yasufumi Ogawa >=20 > 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. >=20 > Cc: stable@dpdk.org >=20 > Signed-off-by: Yasufumi Ogawa > --- > lib/librte_eal/linux/eal/eal_memalloc.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) >=20 > diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/lin= ux/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_l= ist *msl, > struct rte_memseg_list *primary_msl, *local_msl; > char name[PATH_MAX]; > int msl_idx, ret; > + char proc_id[HOST_NAME_MAX] =3D { 0 }; >=20 > if (msl->external) > return 0; > @@ -1374,8 +1375,18 @@ secondary_msl_create_walk(const struct rte_memseg_= list *msl, > local_msl =3D &local_memsegs[msl_idx]; >=20 > /* 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=3D7-8 -v /local/kananye1:/local/kananye1 ubunt= u-dpdk-local:latest /bin/bash And then start dpdk app manually within the container? =20 > + * In docker, hostname is assigned as a short form of full container > + * ID. So use hostname as unique ID among containers instead. > + */ > + if (getpid() =3D=3D 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); >=20 > ret =3D rte_fbarray_init(&local_msl->memseg_arr, name, > primary_msl->memseg_arr.len, > -- > 2.17.1