From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5F658A0547; Wed, 29 Sep 2021 15:32:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CCF76410EA; Wed, 29 Sep 2021 15:32:23 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 8F79A410E5; Wed, 29 Sep 2021 15:32:22 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10122"; a="204428387" X-IronPort-AV: E=Sophos;i="5.85,332,1624345200"; d="scan'208";a="204428387" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2021 06:32:13 -0700 X-IronPort-AV: E=Sophos;i="5.85,332,1624345200"; d="scan'208";a="520833196" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.20.220]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 29 Sep 2021 06:32:05 -0700 Date: Wed, 29 Sep 2021 14:32:02 +0100 From: Bruce Richardson To: Kevin Traynor Cc: dev@dpdk.org, ciara.power@intel.com, anatoly.burakov@intel.com, stable@dpdk.org, David Marchand Message-ID: References: <20210915141030.23514-1-bruce.richardson@intel.com> <20210924161842.2879019-1-bruce.richardson@intel.com> <6ea20d4e-a7dd-afcb-3ca1-ffc023114d72@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ea20d4e-a7dd-afcb-3ca1-ffc023114d72@redhat.com> Subject: Re: [dpdk-dev] [PATCH v2] telemetry: fix "in-memory" process socket conflicts X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Wed, Sep 29, 2021 at 01:28:53PM +0100, Kevin Traynor wrote: > Hi Bruce, > > On 24/09/2021 17:18, Bruce Richardson wrote: > > When DPDK is run with --in-memory mode, multiple processes can run > > simultaneously using the same runtime dir. This leads to each process > > removing another process' telemetry socket as it started up, giving > > unexpected behaviour. > > > > This patch changes that behaviour to first check if the existing socket > > is active. If not, it's an old socket to be cleaned up and can be > > removed. If it is active, telemetry initialization fails and an error > > message is printed out giving instructions on how to remove the error; > > either by using file-prefix to have a different runtime dir (and > > therefore socket path) or by disabling telemetry if it not needed. > > > > telemetry is enabled by default but it may not be used by the application. > Hitting this issue will cause rte_eal_init() to fail which will probably > stop or severely limit the application. > > So it could change a working application to a non-working one (albeit one > that doesn't interfere with other process' sockets). > > Can it just print a warning that telemetry will not be enabled and continue > so it's not returning an rte_eal_init failure? > For a backported fix, yes, that would probably be better behaviour, but for the latest branch, I think returning error and having the user explicitly choose the resolution they want to occur is best. I'll see about doing a separate backport patch for 20.11. > A more minor thing, I see it changes the behaviour from, last one runs with > telemetry, to, first one runs with telemetry. Though it can be figured from > the commit message, it might be worth calling that change out explicitly. > Sure. I'll resubmit a new version of this without stable CC'ed and include that behaviour change explicitly in the commit log. /Bruce