DPDK patches and discussions
 help / color / mirror / Atom feed
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" <techboard@dpdk.org>
Subject: Re: [dpdk-dev] Meson Minimum Version
Date: Thu, 24 Sep 2020 16:43:08 +0100	[thread overview]
Message-ID: <20200924154308.GF382@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <DB6PR0902MB2072D563FB297D1E51A69291B4390@DB6PR0902MB2072.eurprd09.prod.outlook.com>

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.

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-24 15:43 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 [this message]
2020-09-25  7:31   ` Morten Brørup
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=20200924154308.GF382@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=John.Alexander@datapath.co.uk \
    --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).