DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>,
	David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Ray Kinsella <mdr@ashroe.eu>,
	Kevin Laatz <kevin.laatz@intel.com>,
	dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] eal: fix querying DPDK version at runtime
Date: Wed, 17 Mar 2021 10:33:32 +0100	[thread overview]
Message-ID: <4276154.ZrgpHEazGl@thomas> (raw)
In-Reply-To: <CAJFAV8zg-TNcMWwMhQW6cC-7MU+bSKQPoHFgastBn1N+HbEaZQ@mail.gmail.com>

17/03/2021 09:40, David Marchand:
> On Tue, Feb 16, 2021 at 4:13 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > 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}
> >   -->
> >
> > To fix this, we need to convert the rte_version() function, and any other
> > necessary parts of the rte_version.h, to be actual functions in EAL, not
> > just inlines/macros. The only complication in doing so is that telemetry
> > library cannot call rte_version() directly, and instead needs the version
> > string passed in on init.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: stable@dpdk.org
> 
> 
> > diff --git a/lib/librte_eal/include/rte_version.h b/lib/librte_eal/include/rte_version.h
> > index f7a3a1ebc..2f3f727b4 100644
> > --- a/lib/librte_eal/include/rte_version.h
> > +++ b/lib/librte_eal/include/rte_version.h
> > @@ -28,38 +28,47 @@ extern "C" {
> >   * All version numbers in one to compare with RTE_VERSION_NUM()
> >   */
> >  #define RTE_VERSION RTE_VERSION_NUM( \
> > -                       RTE_VER_YEAR, \
> > -                       RTE_VER_MONTH, \
> > -                       RTE_VER_MINOR, \
> > -                       RTE_VER_RELEASE)
> > +                       rte_version_year(), \
> > +                       rte_version_month(), \
> > +                       rte_version_minor(), \
> > +                       rte_version_release())
> 
> It breaks SPDK and applications relying on RTE_VERSION in preprocessor
> directives.
> RTE_VERSION* macros should be left alone, and applications that need
> the runtime value should call rte_version().

Yes, sorry for not catching it before merge.

> See logs in https://lab.dpdk.org/results/dashboard/results/results-uploads/test_runs/2f636aaf4ce244eba20844f9ff006033/log_upload_file/2021/3/dpdk_6857cb635821_2021-03-17_06-34-34_NA.zip

My bad ignoring SPDK build, probably because of other issues there were.

I've sent a fix:
https://patches.dpdk.org/project/dpdk/patch/20210317093124.965624-1-thomas@monjalon.net/



      reply	other threads:[~2021-03-17  9:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05 19:39 [dpdk-dev] [PATCH] " Bruce Richardson
2021-02-05 20:05 ` Thomas Monjalon
2021-02-05 21:26   ` Bruce Richardson
2021-02-09 12:34     ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2021-02-09 12:36       ` Bruce Richardson
2021-02-16 15:13 ` [dpdk-dev] [PATCH v2] " Bruce Richardson
2021-03-15 22:24   ` Thomas Monjalon
2021-03-17  8:40   ` David Marchand
2021-03-17  9:33     ` Thomas Monjalon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4276154.ZrgpHEazGl@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=kevin.laatz@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).