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 EB2C7A32A8 for ; Sat, 26 Oct 2019 20:11:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B77731BF50; Sat, 26 Oct 2019 20:11:45 +0200 (CEST) Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by dpdk.org (Postfix) with ESMTP id 7BD8B1BF50; Sat, 26 Oct 2019 20:11:44 +0200 (CEST) Received: by mail-pl1-f193.google.com with SMTP id t10so3158895plr.8; Sat, 26 Oct 2019 11:11:44 -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=0rvMOMji6yRpBNg/iNvuxMlTNJ/+MJ9YI4PGnXvWA10=; b=F5nz2o5VV+3r1p4+2P9DN2blUW9tVywfUA7i+3Crlw103ybZXaSW2Nk44z2nkjtXv8 R3zFsgfpoiefUMk1cne5aaYXIoga6H1saR906G/FyR83U8w41+8jLrVjVqodlCGrviML Pd1FWYWQTpsoVG2GJx+sI3X15SVVcNVYzgQqOCBMcC4hmRt4bwWwUaczYvC0gdkSJpTD 4vRoorYHZMyHqwhdPdpmF+tGV7929TkvkbUOjLXk6gjd3ay/qIsAHdn+32qVxOjV00sn D6rAeoTHI1Dt+ozCCRvu7F3H0D5xuyk6miVzWSh3uj2dR1cPIK4+d4ul/+OKLPsz5I5+ Zjug== 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=0rvMOMji6yRpBNg/iNvuxMlTNJ/+MJ9YI4PGnXvWA10=; b=tI+0QUj8uwrUM69u4ZlR2ZS+ivd7C+NRkjABv61RartAFszTP7l+AzKH/ZvJ5SOZiX VDwzdFfkois2TgzMa5ad9UtNt7lkiNNnNBfmdwvqeRMYFfjlfX+OpbaOEgvm+XOguhGB rZJn+4/fqTXp0mC3lP2iefiPTFVLyWZKwTD9nesS9k5cERo0Kx9Adp2zKId6m9aG119s GQCcbPB+CRgpQw08ZP6M4InOc/dqEoUGPs91Uo8DxJ2CKI4A2BsFS+Lw/uvK9HKyLeXX XQtYVylYIDrE5iSlo9QJKFsUtHlw7YEfu3/WC+yrz7O1+BbZ5js/zIgzqd7aacodvDZj feKg== X-Gm-Message-State: APjAAAXv4Pzy+9ZPC6aVk15DcSuKrPP6ywUDzRnPwmsCrT/tD7U70lkM y/RwzoGn/NX/a2yuZSI3onw= X-Google-Smtp-Source: APXvYqyI63iCLplUl2smX7Cm2hgSiSyRAOJw/z9n+3IOzWKRuj60qKaZaHV8UTRvWxlCAJAWbpoiqQ== X-Received: by 2002:a17:902:7045:: with SMTP id h5mr10976818plt.236.1572113503590; Sat, 26 Oct 2019 11:11:43 -0700 (PDT) Received: from mugwort.local ([2400:4050:c8c2:de00:359c:a6ad:c72e:c7f6]) by smtp.gmail.com with ESMTPSA id w6sm6214921pfw.84.2019.10.26.11.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Oct 2019 11:11:43 -0700 (PDT) To: David Marchand Cc: "Burakov, Anatoly" , dev , dpdk stable , Yasufumi Ogawa 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> From: Yasufumi Ogawa Message-ID: <8d3e968b-6aae-95ad-7105-730ab63586fa@gmail.com> Date: Sun, 27 Oct 2019 03:11:40 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 2019/10/27 1:15, David Marchand wrote: > 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? Secondary processes can be run from a container. The problem is we cannot run two or more secondary app containers. It is because each of secondary app container tries to create its metadata file and the name is decided with PID, and PID is 1 in all of containers. It means that all of secondaries try to have the same name of metadata file, and failed to create the same file. The first container app can create metadata file with PID 1, but failed to create second one with the same PID 1. This patch is to change creating metadata file from using PID 1 to hostname which is unique in each of secondary containers. To summarize, we can run just one secondary app container without this patch, but cannot two or more secondary app containers. > > >> >>>> 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. >> 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. Thanks. > > >> >>>> >>>>> >>>>> 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_memseg_list *msl, >>>>> struct rte_memseg_list *primary_msl, *local_msl; >>>>> char name[PATH_MAX]; >>>>> int msl_idx, ret; >>>>> + char proc_id[33] = { 0 }; /* 32bytes is enough if using hostname */ >>>> >>>> This variable only makes sense in the if (getpid() == 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? Yes, I will fix it soon. > >> >>>> >>>>> >>>>> if (msl->external) >>>>> return 0; >>>>> @@ -1375,8 +1376,31 @@ 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. >>>>> + * In docker, hostname is assigned as a short form of full container >>>>> + * 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. Thanks. Yasufumi > > > > -- > David Marchand >