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 DCE02A3160 for ; Fri, 11 Oct 2019 11:36:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B32BE1EACD; Fri, 11 Oct 2019 11:36:39 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 702FA1EAC5 for ; Fri, 11 Oct 2019 11:36:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1570786597; 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=qjUS0QsgxIM5ggxjB8H4//ckduN9r7Dhlp6VO8DFWKk=; b=NVJvJ9cIaPSP2rSRDUXNT0Mjgvm6NSN7Iddiesrmqh1Wwiaxm/2qNxsDdN47kOxY8QeCZ6 A5LbKMezNvFcvRL4xDyUGDu/WdPhGUp6n+UontDdb5zedc3aNFCsq4KWt/WxZkz04KwqXk TRfrB723Skj1ZlJO2Q5XpUsASWIeHwY= 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-285-gyyLkyRWOHOwv4hoItInQw-1; Fri, 11 Oct 2019 05:36:36 -0400 Received: by mail-vk1-f200.google.com with SMTP id 70so3202949vkc.7 for ; Fri, 11 Oct 2019 02:36:36 -0700 (PDT) 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=jP3cbf43efGV9jPEhAv/Xa2dvB8ppeebiz6SjVQGW0Q=; b=ij2hmqSs5T8SBM1m7jmlEAYW6hr+MLFksayxuYyyIoHANv/hJIZW4i24d0JB6ZzyAl cncXxDjEB+zRq3N9PQznvaRmMcd+xCsCoOWZVmG4kG/UPqRR84d04oVkcOL8Tbn3EH7z /FaHjm4IE5SyMdVMIbCHN1aInmw9wWngmb3jk5+y1qNIxm9BkNXRFXQTaxl5yNgZxblw ZzgltLeIusR+p5wuKhiaFzCnW6lia43ViHKTese4kbSWdHjX/CJizULluvgCfLDXUgeI MfBRkIlBt0mfcarBvXbT/m0WcLAuDz4jIz/6vxB/E+cjwfjQoOnIFKEKQK17znEGOPVC zahA== X-Gm-Message-State: APjAAAVbTu6ntF2k6RdCsveLT9OVJhei6XPH2SoM9hRaMyt6z4xfGFUJ SWDhab90k/fMxNpHWbvRgTqTpFh+YyUVMf2OMpf+830lYxUgqAGPTXuetbpA9dH1d5VpeFjY+fm Hh1y9F5c/G3U4Wr8qfTU= X-Received: by 2002:a05:6102:1251:: with SMTP id p17mr8430879vsg.141.1570786596033; Fri, 11 Oct 2019 02:36:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqyerNjdKfEW+n4mkTugvWjsapaQnXGn4k7oA/iSTtO/z3KoGCWNdjU9JbqWSqZxZSNaDOdR03RQviKSoA+IDFM= X-Received: by 2002:a05:6102:1251:: with SMTP id p17mr8430866vsg.141.1570786595661; Fri, 11 Oct 2019 02:36:35 -0700 (PDT) MIME-Version: 1.0 References: <20190711103148.9187-1-yasufum.o@gmail.com> <20190724082031.45546-1-yasufum.o@gmail.com> <20190724082031.45546-2-yasufum.o@gmail.com> In-Reply-To: <20190724082031.45546-2-yasufum.o@gmail.com> From: David Marchand Date: Fri, 11 Oct 2019 11:36:24 +0200 Message-ID: To: yasufum.o@gmail.com Cc: "Burakov, Anatoly" , dev , dpdk stable , Yasufumi Ogawa X-MC-Unique: gyyLkyRWOHOwv4hoItInQw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v4 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" Some comments. The title does not reflect the observed issue. I understand that secondary processeses can't be started from a docker container. The patch title should reflect this. On Wed, Jul 24, 2019 at 10:20 AM 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 because hostname is assigned as a short form of 64 > digits full container ID in docker. > > Cc: stable@dpdk.org I don't think we want to backport this behavior change. > > Signed-off-by: Yasufumi Ogawa > --- > lib/librte_eal/linux/eal/eal_memalloc.c | 28 +++++++++++++++++++++++-- > 1 file changed, 26 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/lin= ux/eal/eal_memalloc.c > index 1f6a7c18f..356b304a8 100644 > --- a/lib/librte_eal/linux/eal/eal_memalloc.c > +++ b/lib/librte_eal/linux/eal/eal_memalloc.c > @@ -1366,6 +1366,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[33] =3D { 0 }; /* 32bytes is enough if using hostna= me */ This variable only makes sense in the if (getpid() =3D=3D 1) branch, please move it there, and see below comment about using gethostname(). > > if (msl->external) > return 0; > @@ -1375,8 +1376,31 @@ secondary_msl_create_walk(const struct rte_memseg_= list *msl, > local_msl =3D &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 shou= ld > + * not be decided with pid because getpid() always returns 1. > + * In docker, hostname is assigned as a short form of full contai= ner > + * ID. So use hostname as unique ID among containers instead. I understand this is how it works for docker. Is this the same in other container environments? > + */ > + if (getpid() =3D=3D 1) { > + FILE *hn_fp; > + hn_fp =3D fopen("/etc/hostname", "r"); Why not use gethostname() ? Plus, this api defines the maximum size of the hostname as HOST_NAME_MAX by= tes. > + if (hn_fp =3D=3D NULL) { > + RTE_LOG(ERR, EAL, > + "Cannot open '/etc/hostname' for secondar= y\n"); > + return -1; > + } > + > + /* with docker, /etc/hostname just has one entry of hostn= ame */ > + if (fscanf(hn_fp, "%32s", proc_id) =3D=3D EOF) { > + fclose(hn_fp); > + return -1; > + } > + fclose(hn_fp); > + } else > + sprintf(proc_id, "%d", (int)getpid()); > + > + snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s", > + primary_msl->memseg_arr.name, proc_id); > > ret =3D rte_fbarray_init(&local_msl->memseg_arr, name, > primary_msl->memseg_arr.len, > -- > 2.17.1 > --=20 David Marchand