-----Original Message-----
From: Bruce Richardson <redacted>
Sent: Wednesday, March 31, 2021 11:08 AM
To: Juraj Linkeš <redacted>
Cc: Honnappa Nagarahalli <redacted>; Jerin Jacob
[off-list ref]; Ruifeng Wang [off-list ref];
vcchunga@amazon.com; Dharmik Thakkar [off-list ref];
hemant.agrawal@nxp.com; Ajit Khaparde (ajit.khaparde@broadcom.com)
[off-list ref]; ferruh.yigit@intel.com; aboyer@pensando.io;
lironh@marvell.com; dev@dpdk.org; nd [off-list ref]
Subject: Re: [PATCH v16 1/3] build: disable/enable drivers in Arm builds

On Wed, Mar 31, 2021 at 08:39:57AM +0000, Juraj Linkeš wrote:

quoted

quoted

-----Original Message-----
From: Honnappa Nagarahalli <redacted>
Sent: Tuesday, March 30, 2021 2:39 AM
To: Jerin Jacob <redacted>; Juraj Linkeš
[off-list ref]
Cc: Bruce Richardson <redacted>; Ruifeng Wang
[off-list ref]; vcchunga@amazon.com; Dharmik Thakkar
[off-list ref]; hemant.agrawal@nxp.com; Ajit Khaparde
(ajit.khaparde@broadcom.com) [off-list ref];
ferruh.yigit@intel.com; aboyer@pensando.io; lironh@marvell.com;
dev@dpdk.org; nd [off-list ref]; Honnappa Nagarahalli
[off-list ref]; nd [off-list ref]
Subject: RE: [PATCH v16 1/3] build: disable/enable drivers in Arm
builds

<snip>

quoted

quoted

<removed parts which I think are not that relevant>

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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=bui
ld/e
xt
erna
l/pa
ckag es/dpdk
.mk;h=c35ac84c27b19411a0cfdf9a3524fdf36024762c;hb=HE
AD

They're disabling almost everything so an allowlist would fit

there.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

quoted

quoted

quoted

quoted

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?

quoted

quoted

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?

Nothing Arm specific. I think for generic Arm servers platforms we
can make sure that we allow for compilation of all the DPDK code. We
can go ahead with implementing the allow list.

I tried to actually use an allowlist and there are some problems with building

apps and tests. When I tried to enable a random driver, such as
common/sfc_efx, I've ran into dependency issues with apps:

quoted

app/meson.build:53:3: ERROR:  Tried to get unknown variable

"static_rte_bus_vdev".

quoted

This is because bus/vdev is not enabled (the allowlist only enabled

net/sfc_efx). When I implemented dependency discovery in apps similar to
which exists for drivers/libs, I was then unable to build tests (which is a special
case app):

quoted

app/test/meson.build:427:1: ERROR:  Tried to get unknown variable

"static_rte_bus_pci".

quoted

This is becasue bus/pci is not enabled. If I understand the code correctly, the

test dependencies are not matched to each test, meaning we can't disable the
tests for which we don't have dependencies - we can only disable all tests.

quoted

In general, this problem also affects the blocklist, i.e. meson build
-Ddisable_drivers=bus/pci produces
drivers/net/hinic/base/meson.build:34:0: ERROR:  Unknown variable

"static_rte_bus_pci".

quoted

For blocklists, this is seldom going to be a problem, since most users won't

disable "core" drivers.

quoted

I'm not sure what is the best course of action. We can implement the allowlist

and then we'll leave it up to implementers to implement allowlists that produce
a working build. We could then optionally address the dependency issues
brought by disabled drivers in a separate patch.

quoted

Maybe we can just have a list of "core" drivers that can never be disabled

(either using blocklists or allowlists)?

quoted

Bruce, what do you think?

Hi,

from my experience this mainly seems to affect the bus drivers, specifically pci
and vdev buses, which seem to be assumed to be always enabled. I agree it's
probably not a real problem right now, though it would be nice for some testing
purposes to have a build possible with "disable_drivers=*/*". For a solution I am
happy for us to have whichever is easiest to implement - either refusing disabling
of bus/pci and bus/vdev, or fixing the tests and apps to allow them to be built
with reduced functionality.

Apart from those two drivers, I would hope that disabling everything else works.
If not, we should definitely fix it.

I tried with just those two enabled and it works. I'll introduce a list of drivers that won't ever be disabled (ther other solution is more complicated and I think out of scope of this patch) and submit a new version.

/Bruce