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

Jerin Jacob jerinjacobk at gmail.com
Fri Mar 19 14:32:08 CET 2021


On Fri, Mar 19, 2021 at 6:51 PM Juraj Linkeš <juraj.linkes at pantheon.tech> wrote:
>
> <removed parts which I think are not that relevant>
>
> > > > > > > > > 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/externa
> > > > > > > l/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?
> >
> > Just to understand, how end customer can enable allow list, if DPDK build system
> > does not support it?
> > Also to understand, If we are supporting blocklist, why not have allowlist (I
> > mean, both of them) as both are required as it caters different use case as
> > mention above. We can not emulate allowlist with blocklist as each version of
> > DPDK will have new libraries and PMD's which end user has no clue. Right?
>
> > I think, that is the reason why VPP is doing the allow list.
>
> I'm not sure what you mean by this, but to clarify, VPP likely would be using the allowlist in this fashion, but that is not an arm specific usecase. I think what Honnappa wanted to see was how the allowlist could be used in an arm usecase (such as using it in an SoC configuration).

There is nothing arm-specific here. Right? allowlist will be common
and will be used by all architecture. Right?


>
>


More information about the dev mailing list