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

Jerin Jacob jerinjacobk at gmail.com
Wed Mar 10 10:12:36 CET 2021


On Wed, Mar 10, 2021 at 1:12 PM Juraj Linkeš <juraj.linkes at pantheon.tech> wrote:
>
>
>
> > -----Original Message-----
> > From: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>
> > Sent: Tuesday, March 9, 2021 8:55 PM
> > To: Juraj Linkeš <juraj.linkes at pantheon.tech>; Jerin Jacob
> > <jerinjacobk at gmail.com>
> > 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/exter
> > > > > > > > na
> > > > > > > > l/
> > > > > > > > pa
> > > > > > > > ck 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.
> > > > That's confusing.
> > > > If a platform like bluefield has an allow list, a new PMD that gets
> > > > added will not be compiled for that platform unless someone
> > > > explicitly adds
> > > it to the allow list.
> > > > Is my understanding correct?
> > >
> > > Yes.
> > With this it becomes very easy to skip compiling on a platform.
> >
>
> It wouldn't be mandatory. Maybe I should've said we would be able to choose between three behaviors - the current (where everything is built), with allowlist or with blocklist.
>
> But maybe the worry is that someone will use the allowlist without fully understanding the consequences?
>
> > >
> > > > Whereas if the bluefield platform had a block list, then the new PMD
> > > > would be compiled for bluefield platform.
> > > >
> > >
> > > Again, yes.
> > >
> > > Supporting both would give us the option to choose between the two
> > > behaviors.
> > >
> > > > >
> > > > > > 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.
> > > > Sorry, may be this is answered already, but, what additional benefit
> > > > does allowlist provide over the blocklist?
> > > >
> > >
> > > VPP could use it:
> > > https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=build/external/packag
> > > es/dpdk .mk;h=c35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=HEAD
> > >
> > > They're disabling almost everything so an allowlist would fit there.
> > > And they won't need to update the list when a new driver is added
> > > (which they won't need).
> > This is different from how we started this discussion. The current discussion was
> > for DPDK internal use. But the one you are referencing above is for users of
> > DPDK. I am fine for providing the allow list for the users of DPDK. But for DPDK
> > internal, I think block list is enough.
> >
>
> That's an interesting suggestion. Jerin, what do you think? Why did you want to have an allowlist? Would this work?

# The very reason why VPP chooses to have allow list so that they can
control what needs to include.
# Another use case is like, in SoCs have fixed internal devices, we
can have optimized build for that can have only allow list
of the drivers that care about
# For server market, block list makes sense
# For embedded SoC, allow list makes sense.
# Ideal situation is if we support both.
# I dont quite understand the above comments for internal use vs
external use. If it is exposed
as a meson option then I think, it does not matter. Right?

>
> > >
> > > I think it was Jerin who suggested the allowlist. I don't know of an
> > > Arm usecase for it, but maybe he has an example.
> > >
> > > > >
> > > > > > 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