From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <stable-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 392AA42CA7 for <public@inbox.dpdk.org>; Tue, 13 Jun 2023 18:51:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3083341611; Tue, 13 Jun 2023 18:51:20 +0200 (CEST) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mails.dpdk.org (Postfix) with ESMTP id 38B7340C35 for <stable@dpdk.org>; Tue, 13 Jun 2023 18:51:17 +0200 (CEST) Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1b3d8aa2c17so12676885ad.3 for <stable@dpdk.org>; Tue, 13 Jun 2023 09:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1686675076; x=1689267076; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=UWdVMh1FjCSd50bPM3XcMf3XHfVTn9DDDt0xz9D+3qs=; b=tvkQaaT7zJQammEM2v1KqpwYObHphaKCi2wo3ZrEnde6WPos89lpIDjipqEgkGeUPn at5Fis8FRFiuThauQxhimoIMRBJg4l11wgKJGPCBraE6NpwGXrU34p0y9weS4jwpCyGX SPHSh17YarkvyHENSSzDSeq/jYFhR7S6W+fAPGQ2QDEvPLpz4dT82WsHtVcEKxzS1VmE YasuIaXRvismI31n+ZYk/iCtBaHGiDNDlwMKFWsOJBZ2tLOUbdllhsnelC9kpHqL6JKE zvlkdmv7topqs0xXdFGShUyr73sRYu/RviXtmeuXqHeKOkkh5wb/zWIYgK49t7gzv6PU aWHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686675076; x=1689267076; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UWdVMh1FjCSd50bPM3XcMf3XHfVTn9DDDt0xz9D+3qs=; b=E5Yybq/PX8MuW/vWLnEoZmD+X84Q0Vr8K/DF6+eK7B2StmcZQybAfCWuYYCgy3sbeO NrSQvFpEC89WpcBxyWPpWzuM5zESH/PlVElNZdzr8uiwiUfk3qCcARR/be3Vbbsv2pQH A1dxY/0k2K3bgorf9RwPrB3fOCFmizSoKKmbHt8tHmwTT9h5ayQf/BsIB8s4muWiSAdd T29GogVctZxAcsrRbmY1F/0EERgueQFg1jHwAqY97rQin5ehhDYAm6RRADp3bp4wPQEF vUrLCf/Y8iWd9/LKH8u5qC7hRrus6TvPYZJKM3JD2DGGme95oxWWadGKTpcPuRArSshw vtUw== X-Gm-Message-State: AC+VfDzbfHFH1q1ZqW558W9SaF2wTkvepITvxOUb/ZblgC3MUQcqdRC1 Qns33gg29/587avgRdDL7gfODQ== X-Google-Smtp-Source: ACHHUZ4j2a5QVZms0Xw6UYbrNUxI/6dkwMO5/gPqP/t90S7RF+SJs+40LAGIcL29Pn+SQham7rg6Qg== X-Received: by 2002:a17:902:c20b:b0:1af:d9d2:a234 with SMTP id 11-20020a170902c20b00b001afd9d2a234mr9353781pll.3.1686675076226; Tue, 13 Jun 2023 09:51:16 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id iy18-20020a170903131200b001b3d27a7820sm3987636plb.234.2023.06.13.09.51.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jun 2023 09:51:16 -0700 (PDT) Date: Tue, 13 Jun 2023 09:51:14 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: ogawa.yasufumi@lab.ntt.co.jp Cc: anatoly.burakov@intel.com, dev@dpdk.org, stable@dpdk.org Subject: Re: [dpdk-dev] [PATCH] fbarray: get fbarrays from containerized secondary Message-ID: <20230613095114.7b0ef843@hermes.local> In-Reply-To: <1555379952-23517-1-git-send-email-ogawa.yasufumi@lab.ntt.co.jp> References: <1555379952-23517-1-git-send-email-ogawa.yasufumi@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches <stable.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/stable>, <mailto:stable-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/stable/> List-Post: <mailto:stable@dpdk.org> List-Help: <mailto:stable-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/stable>, <mailto:stable-request@dpdk.org?subject=subscribe> Errors-To: stable-bounces@dpdk.org On Tue, 16 Apr 2019 10:59:12 +0900 ogawa.yasufumi@lab.ntt.co.jp wrote: > From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp> > > 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 as expected if secondary is run as app container becuase > each of containerized secondary has PID 1. To reserve unique name, use > hostname instead of PID if the value is 1. > > Cc: stable@dpdk.org > > Signed-off-by: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp> > --- Since this is an ABI break. I propose that a more invasive solution would be better. Either change to using something more unique GUID or change the fbarray structure to be a variable length array. The internals of fbarray should also be hidden (ie not in rte_fbarray.h) and the init() function changed into something that allocates the array. The current patch has not gotten any followup or acceptance in 4 years. So marking it as changes requested.