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

[Honnappa Nagarahalli]

<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/e
> > > > > > > > > xter
> > > > > > > > > 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?
Yes.

> >
> > > >
> > > > > 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/pa
> > > > ckag 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.
For the embedded SoC, IMO, the upstream project could allow the compilation for wider set of PMDs/libs. May be the end customer can use the allow list to compile/use what is required?
For ex: we use PCIe interfaces with external NICs for the embedded SoCs (where there is support).
I think the list of PMDs/libs enabled/disabled on a given platform is another discussion. This should not prevent us from supporting the allowlist.

> # 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
> > > > > > > > >