[dpdk-stable] [PATCH] eal: fix querying DPDK version at runtime

Bruce Richardson bruce.richardson at intel.com
Tue Feb 9 13:36:58 CET 2021


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.


More information about the stable mailing list