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 F4239A32A8 for ; Sat, 26 Oct 2019 18:16:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BB42C1BF7D; Sat, 26 Oct 2019 18:16:14 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id EB9A31BF6A for ; Sat, 26 Oct 2019 18:16:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572106571; 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=FbqB4UW9gauHJk6PXSvr10UAVHY4w0SEA0rzPiz1M6o=; b=hBbAnRQzHRHO/D0vtdha9Jw2+Yqqpx3y5qcUFgFnzUReAZmjzEWL/F83ny3YXYjG/sBdXa SeIFu68p3KB2B9VI5cOEXTkTwyxssIm+zyAm8cIEOg0Cmdmu8t7eC7H0/iL3iSreuPxx9J yFQFfIkK3hfGNIhqbo7lVgoKsKa+/nw= 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-217-80qKgNPQPN2lZycuph-01A-1; Sat, 26 Oct 2019 12:16:10 -0400 Received: by mail-vk1-f198.google.com with SMTP id i207so989120vke.21 for ; Sat, 26 Oct 2019 09:16:10 -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=KB5O0t/SD3i5WI+RoEXnpxlBfv1y1RgmjGRluaz1phE=; b=ZEolitwRaGGPWJZLnUsAz2cT7tF2H4ap98ap+SJZnQNgz4gf1WJ111VXVOlYJg6bVP rhroOeJ9tve4Pp5t9IR54m61FR0WuBsmDGdfMxI2uPmE052kIv2R0HUzn1M1o3PlbcnH lzMOV+8sRVhwm9i3WBBLYgoJ9DhwjLhu/C4ywz0c8XSFJRAOwnOk8MBzaC8pz98Muu4K EOZV+1rehp3WYF1Bnf+3SkWg8zAfh7cSVJvCAbAcn45iDq0d3ExOueZGfyx4Zo28oAcN up1Q9RibVTaYwINfC8OcAhzSDyNX38H5OkCwIawO8ExsyM7aqIIkx818h8Qpr7bESuGY 883A== X-Gm-Message-State: APjAAAWBQZUdMym9y4Izr7UF+w5wKVh/7LHgV5FfRZk0ruJIS9o6qC4V piwD19PLO6PksxCFKH+o6fzl7haa41RZmpld/6RAynMJWZ3PUlvhDlpNUIt5RYNW+TpNHAoxrQT ESW3htWaJO2VMdVNCTnUo7xs= X-Received: by 2002:a67:7790:: with SMTP id s138mr828231vsc.198.1572106567776; Sat, 26 Oct 2019 09:16:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJPsIw/O0nREfAsNZclJIViaA9UQXtA2NyetFC4uePbeDmDujjSpG3VaBwTRdFC+d2PVg0Klh20cutOZMWfFE= X-Received: by 2002:a67:7790:: with SMTP id s138mr828144vsc.198.1572106565647; Sat, 26 Oct 2019 09:16:05 -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> <4c23f77e-cf00-2785-f0ce-34081c393011@gmail.com> In-Reply-To: <4c23f77e-cf00-2785-f0ce-34081c393011@gmail.com> From: David Marchand Date: Sat, 26 Oct 2019 18:15:54 +0200 Message-ID: To: Yasufumi Ogawa Cc: "Burakov, Anatoly" , dev , dpdk stable , Yasufumi Ogawa X-MC-Unique: 80qKgNPQPN2lZycuph-01A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [PATCH v4 1/1] fbarray: get fbarrays from containerized 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 Fri, Oct 25, 2019 at 9:55 PM Yasufumi Ogawa wrote: > >> > >> The title does not reflect the observed issue. > I would like to consider to revise it. > > >> I understand that secondary processeses can't be started from a docker > >> container. > I've confirmed that secondary process can be started as a container app > with SPP, and DPDK v18.08 and v19.08. SPP is a multi-process app > supporting container usecases. > http://git.dpdk.org/apps/spp/ Sorry, I don't understand. Do you mean the secondary processes can be run from containers without this patch? Or once this patch is applied? > > >> 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 i= ts > >>> 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 hostna= me > >>> 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. > This issue was included from DPDK v18.08, and some users of SPP are > still using stable 18.11. So, I would appreciate if you agree to backport= . This can be discussed later. Ok to keep stable in CC: then. > > >> > >>> > >>> 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= /linux/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_mems= eg_list *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 ho= stname */ > >> > >> This variable only makes sense in the if (getpid() =3D=3D 1) branch, > >> please move it there, and see below comment about using gethostname(). > Sure. It works correctly in secondary app container and I should replace = it. Great, can you send a new version of this patch? > > >> > >>> > >>> if (msl->external) > >>> return 0; > >>> @@ -1375,8 +1376,31 @@ secondary_msl_create_walk(const struct rte_mem= seg_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 = should > >>> + * not be decided with pid because getpid() always returns 1. > >>> + * In docker, hostname is assigned as a short form of full co= ntainer > >>> + * 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? > Umm... I've tested on other than docker because I don't have test > environment. I am not sure which of container runtimes should be > supported actually. I think it is enough as the first step to fix this > issue of docker. Moreover, the essential problem is that getpid() > returns 1 in docker or not. > > I am also not sure which of environments other than docker should be > supported if necessary. What do you think? No problem if you don't know. -- David Marchand