[dpdk-dev] [PATCH v16 1/3] build: disable/enable drivers in Arm builds

Juraj Linkeš juraj.linkes at pantheon.tech
Tue Mar 9 16:49:49 CET 2021



> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>
> Sent: Tuesday, March 9, 2021 4:09 PM
> To: Jerin Jacob <jerinjacobk at gmail.com>; Juraj Linkeš
> <juraj.linkes at pantheon.tech>
> Cc: Bruce Richardson <bruce.richardson at intel.com>; Ruifeng Wang
> <Ruifeng.Wang at arm.com>; vcchunga at amazon.com; Dharmik Thakkar
> <Dharmik.Thakkar at arm.com>; hemant.agrawal at nxp.com; Ajit Khaparde
> (ajit.khaparde at broadcom.com) <ajit.khaparde at broadcom.com>;
> ferruh.yigit at intel.com; aboyer at pensando.io; lironh at marvell.com;
> dev at dpdk.org; nd <nd at arm.com>; nd <nd at arm.com>
> Subject: RE: [PATCH v16 1/3] build: disable/enable drivers in Arm builds
> 
> <snip>
> 
> > > >
> > > > On Tue, Mar 09, 2021 at 08:58:39AM +0000, Juraj Linkeš wrote:
> > > > > Honnappa, Thomas, Bruce, Jerin, you've comments in the past. Do
> > > > > you have
> > > > any further input?
> > > > >
> > > > > I think we just need to agree on the allowlist/blocklist
> > > > > mechanism. The current
> > > > commit allows specifying either an allowlist or a blocklist, but not both.
> > > > However, it would possible to implement specifying both - first
> > > > we'll allow what's in allowlist and then we'll remove from that
> > > > set what's
> > in blocklist.
> > > > Thoughts?
> > > > >
> > > >
> > > > If we have both, I think limiting to only one is by far the sanest option.
> +1
> 
> > > > I'm not fully convinced by the need to have both, since the
> > > > blocklist allows wildcarding and exception cases. For example
> > > > "net/[!i]*" will blocklist all net drivers except those starting
> > > > with an "i". Admittedly, for usability purposes having an
> > > > allowlist might
> > work better.
> > > >
> > >
> > > If we only want to build a handful of drivers then the list could be
> > > very long
> > (which was the original reason behind having an allowlist), such as here:
> > > https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=build/external/pack
> > > ag es/dpdk.mk;h=c35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=HEAD
> > >
> > > An allowlist could also help with maintenance - users won't need to
> > > add
> > new drivers to their blocklists (if that's what users need, like in
> > the case of VPP).
> >
> > +1 for allowlist.
> May be I am missing something here. By creating an allowlist, does it mean
> drivers are disabled (from compilation) by default? For a server platform, where
> almost all the drivers can be compiled, does the allowlist contain all the drivers?
> 

If no allowlist is specified, then everythin will be built - nothing will be filtered.

> If we assume by default everything should compile on Arm platform, but allow
> for few exceptions (where things are really painful to fix, for ex: compiler needs
> to be fixed), having a blocklist should be shorter/better?
> 

The blocklist is, I think, agreed upon by everyone. The question is whether we want to support the allowlist alongside it and there seem to be enough reasons to do that.

> By having an allowlist, we will end up with a large part of the code that might
> not compile on Arm platforms.
> 
> >
> > >
> > > > One final thought, if we add a driver allowlist for cross files,
> > > > should we also add one as a top-level meson option also for consistency?
> > > >
> > >
> > > This definitely makese sense. I was thinking about this and wasn't
> > > sure
> > whether I should put it into this commit or a separate one. The commit
> > evolved a bit and now that it's just an implementation of an
> > allow/blocklist it makes sense to include a meson option in it I think
> > - I'll put it into the next version.
> > >
> > > > /Bruce
> > >


More information about the dev mailing list