DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>,
	"John Alexander" <John.Alexander@datapath.co.uk>
Cc: <dev@dpdk.org>, <techboard@dpdk.org>
Subject: Re: [dpdk-dev] Meson Minimum Version
Date: Fri, 25 Sep 2020 09:31:53 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61326@smartserver.smartshare.dk> (raw)
In-Reply-To: <20200924154308.GF382@bricha3-MOBL.ger.corp.intel.com>

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, September 24, 2020 5:43 PM
> 
> On Thu, Sep 24, 2020 at 03:32:41PM +0000, John Alexander wrote:
> >    Hi,
> >    Regarding the subproject local patch support, yes, it's only
> supported
> >    since Meson 0.55:
> >    https://mesonbuild.com/Wrap-dependency-system-manual.html We pip
> >    installed 0.55 Meson.
> >    I have a number of subsequent patches that depend on this
> particular
> >    pthreads library to advance the Windows DPDK support. Locally, we
> have
> >    testpmd (minus mmap'd external memory currently) running against
> the
> >    Intel i40e PMD (XL710 4x10Gbps SPF+ NIC) on Windows on our local
> DPDK
> >    fork (based off 20.08-rc2 using Microsoft's latest NetUIO driver).
> We
> >    have 47 of the 51 RTE libraries building and have had l2fwd,
> l3fwd,
> >    ipv4_multicast and almost all of the regression tests
> compiling+linking
> >    too. I'd like to push as much of the Windows EAL work we've done
> >    upstream if I can (after a bit of tidying up :).
> >    I've also coded up a meson build patch for the Jansson JSON parser
> used
> >    by the RTE metrics library (the config.h generation was quite
> fiddly!)
> >    That's ready to go. We get nice meson syntax as follows to specify
> a
> >    fallback if the library isn't installed locally:
> >    jansson = dependency('jansson', required: false, fallback :
> ['jansson',
> >    'jansson_static_dep'])
> >    I believe the meson command line enables disabling fallbacks if
> people
> >    would prefer not to use them (--wrap-mode=nofallback).
> >    Kind regards,
> >    John.
> 
> Hi again, John,
> 
> thanks for the full reply - the work you have sounds really good, and
> the
> possibilities using the wrap support are definitely of interest.
> [Though
> since jansson is only used for the legacy parts of the telemetry
> library
> I'm not sure we want to wrap it just for that - the later telemetry
> work
> from this year doesn't depend on jansson. Then again, the
> vm_power_manager
> example also uses it too...]. It's probably something that would be
> especially useful for software dependencies that aren't normally
> packaged.
> 
> I've added techboard on CC to previous reply, so hopefully we'll get
> some
> thoughts from others.
> 

A buggy C compiler might generate buggy code, and the compiler induced bugs may not be caught during development (but hopefully during testing). I have seen this happen, and I still consider it a realistic scenario. This is the strongest argument for using a trusted version of the C compiler, which is supported by the popular GNU/Linux distributors (Red Hat etc.), or sufficiently vetted to be included in the Crosstool-NG project, or similar.

Meson is a relatively simple tool, so I personally wouldn't mind overwriting the distro-supported version on our build systems with a new version. (I haven't worked much with Meson, but assume that the new version of Meson is backwards compatible with its earlier versions.)

In short, my primary concern is: What could realistically go wrong if the required version of Meson is buggy?

Bruce, you have worked for quite a while with Meson/Ninja by now, so perhaps you can assess this risk based on your experience.


> Regards,
> /Bruce
> 
> PS: please don't top-post in replying and keep plain text email if
> possible. Thanks.
> 
> >    ------------------------------------------------------------------
> ----
> >    Date: Thu, 24 Sep 2020 15:38:30 +0100
> >    From: Bruce Richardson <bruce.richardson@intel.com>
> >    To: John Alexander <John.Alexander@datapath.co.uk>
> >    Cc: "dev@dpdk.org" <dev@dpdk.org>, techboard@dpdk.org
> >    Subject: Re: [dpdk-dev] Meson Minimum Version
> >    Message-ID: <20200924143830.GD382@bricha3-MOBL.ger.corp.intel.com>
> >    Content-Type: text/plain; charset=us-ascii
> >    On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> >    > Hi,
> >    >
> >    > I've submitted a patch that uses new features of Meson,
> specifically
> >    the directory patch aspect of the subproject feature. This
> requires a
> >    minimum Meson version of 0.55.0. How do we go about getting the
> >    community to accept a more recent version of Meson and getting the
> >    Travis server upgraded too so the CI builds succeed?
> >    >
> >    > Patch link for reference: http://patches.dpdk.org/patch/78675/
> >    >
> >    Hi John,
> >    from what I understand the specific dependency on 0.55 is the
> support
> >    for local patchfiles for the wrapped software, and that previous
> >    versions only supported using patches pulled remotely - is that
> >    correct?
> >    While I'm in favour of incrementing the minimum meson version in
> >    general, since 0.55 is the very latest version I am worried about
> any
> >    impacts that might have, since it will basically mean that
> everyone
> >    building DPDK has to pull meson from pip rather than being able to
> use
> >    a distro-supplied version. Updating to something a little less
> recent
> >    would be more my preference.
> >    Then again, using the wrap system to pull in dependencies seems
> >    something really good to have, so maybe the initial pain of
> requiring a
> >    recent meson is worth it!
> >    Thoughts from others?
> >    Regards,
> >    /Bruce
> >
> >    John Alexander​
> >    Senior Software Engineer
> >    Bemrose House, Bemrose Park, Wayzgoose Drive ,  Derby ,  DE21 6XQ
> >    [1]+44 (0)1332 294 441  |  [2]www.datapath.co.uk
> >    [3]LinkedIn
> >    [4]Twitter
> >    [5]YouTube
> >    [6]Vote for Datapath
> >    Datapath Ltd.  Registered Number: 1609392.  Registered in England
> at Be
> >    mrose House, Bemrose Park, Wayzgoose Drive, Derby. DE21 6XQ.
> >
> > References
> >
> >    Visible links
> >    1. tel:+44%20(0)1332%20294%20441
> >    2. http://www.datapath.co.uk/
> >    3. https://www.linkedin.com/company/datapath-ltd
> >    4. https://www.twitter.com/datapathltd
> >    5. https://www.youtube.com/datapathderby
> >    6. https://nbmedia.wufoo.com/forms/z17utbme1olkvqz/
> >
> >    Hidden links:
> >    7. http://www.datapath.co.uk/
> 


  reply	other threads:[~2020-09-25  7:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 15:32 John Alexander
2020-09-24 15:43 ` Bruce Richardson
2020-09-25  7:31   ` Morten Brørup [this message]
2020-09-25  8:41     ` Bruce Richardson
2020-09-25  8:58       ` Morten Brørup
2020-09-25  9:19       ` Dmitry Kozlyuk
2020-09-25  9:22         ` Bruce Richardson
  -- strict thread matches above, loose matches on Subject: below --
2020-09-24 14:22 John Alexander
2020-09-24 14:38 ` Bruce Richardson
2020-10-09 15:59 ` Bruce Richardson
2020-10-09 16:15   ` John Alexander

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=98CBD80474FA8B44BF855DF32C47DC35C61326@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=John.Alexander@datapath.co.uk \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=techboard@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).