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 0A0BFA0548 for ; Tue, 9 Feb 2021 13:37:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE48D1606BA; Tue, 9 Feb 2021 13:37:07 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 24D3240147; Tue, 9 Feb 2021 13:37:04 +0100 (CET) IronPort-SDR: 4ytJvdVZ1fGo2rRL3hZS0IK3On8L2O+pXYs4IHZaLo05F77Y0YC1zfaXdvaW0rsnzsU4QDKo+Z y2y5ks0fsyjQ== X-IronPort-AV: E=McAfee;i="6000,8403,9889"; a="181934462" X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="181934462" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2021 04:37:03 -0800 IronPort-SDR: zRFQibwtI4sJa28elfCnEckp+/d2hPNlYTHfXraYPlNV+qeHwnF1sjoSGqfdsPMDyobn0Y7Gis +U2Y541wi3Ew== X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="396103733" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.24.112]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Feb 2021 04:37:01 -0800 Date: Tue, 9 Feb 2021 12:36:58 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: stable@dpdk.org, dev@dpdk.org, david.marchand@redhat.com, Ray Kinsella , Neil Horman , Kevin Laatz Message-ID: <20210209123658.GC1208@bricha3-MOBL.ger.corp.intel.com> References: <20210205193933.410011-1-bruce.richardson@intel.com> <1695007.lsEMqjsl9x@thomas> <20210205212606.GA1479@bricha3-MOBL.ger.corp.intel.com> <2748803.ThAVpoFO8R@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2748803.ThAVpoFO8R@thomas> Subject: Re: [dpdk-stable] [PATCH] eal: fix querying DPDK version at runtime X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 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 Tue, Feb 09, 2021 at 01:34:40PM +0100, Thomas Monjalon wrote: > 05/02/2021 22:26, Bruce Richardson: > > On Fri, Feb 05, 2021 at 09:05:43PM +0100, Thomas Monjalon wrote: > > > 05/02/2021 20:39, Bruce Richardson: > > > > For using a DPDK application, such as OVS, which is dynamically linked, the > > > > DPDK version in use should always report the actual version, not the > > > > version used at build time. This incorrect behaviour can be seen by > > > > building OVS against one version of DPDK and running it against a later > > > > one. Using "ovs-vsctl list Open_vSwitch" to query basic info, the > > > > dpdk_version returned will be the build version not the currently running > > > > one - which can be verified using the DPDK telemetry library client. > > > > > > > > $ sudo ovs-vsctl list Open_vSwitch | grep dpdk_version > > > > dpdk_version : "DPDK 20.11.0-rc4" > > > > > > > > $ echo quit | sudo dpdk-telemetry.py > > > > Connecting to /var/run/dpdk/rte/dpdk_telemetry.v2 > > > > {"version": "DPDK 21.02.0-rc2", "pid": 405659, "max_output_len": 16384} > > > > > > Nice demonstration. > > > > > > > __rte_experimental > > > > int > > > > -rte_telemetry_init(const char *runtime_dir, rte_cpuset_t *cpuset, > > > > +rte_telemetry_init(const char *runtime_dir, const char *rte_version, rte_cpuset_t *cpuset, > > > > const char **err_str); > > > > > > It is changing the API. > > > As it is experimental, you just need to mention it in the release notes. > > > > I don't think I actually need to mention it there, because this API is more > > "INTERNAL" than "EXPERIMENTAL". It's called automatically from > > rte_eal_init(). I've done up patch http://patches.dpdk.org/patch/87806/ > > to correct this, including a RN addition. That should remove the need for a > > doc update for this patch. > > > > > > > > It is the fix. Do you think it should be merged quickly? > > > Or wait for 21.05? > > > > > > > I'm not sure either way to be honest. Given the bug has been around so > > long, it's not exactly urgent. On the other hand, to get the fix the user > > needs to rebuild their app, so having it sooner is nicer, and will mean it > > would make the next LTS point release. Overall, though, I'm fine whichever > > you decide. > > > There is not much help available to close 21.02, so I won't take any risk. > I'll merge this fix in 21.05. > > I agree that it's not urgent enough to risk taking in 21.02. Taking it in 21.05 is fine, thanks.