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 5E7D9A32A8 for ; Sat, 26 Oct 2019 18:16:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2E52E1BF74; Sat, 26 Oct 2019 18:16:12 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 5646B1BF6A for ; Sat, 26 Oct 2019 18:16:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572106569; 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=cIkgVA5Rc4NBeausUu30K00bM4Hl1+VtZ87gckVFZmcwJiykgjUSDbRTf1IJnPAdbbchZS E5J8q5/AUVAPMfqOvTWL7VTTNhYzrrgnnTBKBbEGA4gCODbPXZi8KqyzvoRUS5ui8jW5nQ HLH+a6zVH8DBxoKMlIFDm1+0c1CtH6M= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-84-uu9cvZWhPqWNWEYz6iMIng-1; Sat, 26 Oct 2019 12:16:08 -0400 Received: by mail-vk1-f197.google.com with SMTP id i207so989077vke.21 for ; Sat, 26 Oct 2019 09:16:08 -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=ln6copsf1hnH7vEkRp7cEN5lg8MVSj2xuN3A4YGLMXdmO9rzueRujVxKt0wSnGfOte MfzdMOqH1Gt96e4VDaOSNgu7TwIMrZsGeKg7HFt471ypgBZl6oUCJ8ZjuTn1cmiJpbSS gZTEVOyefL0hbadOHt715p8nunlSUs7Q1aik2nhHEkz8wHB7t1QlTg53sRw0IxAiJ5EL EjulcviGTfoC3/4suDwrazt6+FRhEy3Mfvpl49aAX9a55C1uCE/oAkDpENYBlrZzX1I7 NowdHQMvqR6KRS9DD2OHt51wlEYI1bREGOR5PbHxO1Lz3twAO4T2Hk7uIztfdfeSPzgg ypkA== X-Gm-Message-State: APjAAAWwCp46wVRLuKdQmzC4D8++wpLPFAlFii52Y5mXL4FxgIYYzgXZ 5Tz+AEwAfUddyxEQplL1MBSuIi6id7L2zGA+GlGiCWG3k93IRtXxUKDpEM4eeXhZP+/KFIgQB8j n0EY87eKyZuS73OtkVmE= X-Received: by 2002:a67:7790:: with SMTP id s138mr828222vsc.198.1572106567540; 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: uu9cvZWhPqWNWEYz6iMIng-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" 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