diff mbox series

[v15,09/12] build: disable drivers in Arm builds

Message ID 1610717170-31279-10-git-send-email-juraj.linkes@pantheon.tech (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers show
Series Arm build options rework | expand

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Juraj Linkeš Jan. 15, 2021, 1:26 p.m. UTC
A few options that disabled drivers in the old makefiles were improperly
ported to the meson build system. Fix this by adding a to the list of
disabled drivers, similarly how the command line option works and remove
unneeded driver options ported from the old makefile system, since they
don't work in the current Meson build system.
Add support for removing drivers for cross builds so that we can disable
them in cross files.

Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
 config/arm/arm64_armada_linux_gcc                   | 1 +
 config/arm/meson.build                              | 7 +++----
 doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 4 ++++
 drivers/meson.build                                 | 6 +++++-
 meson.build                                         | 1 +
 5 files changed, 14 insertions(+), 5 deletions(-)

Comments

Thomas Monjalon Jan. 18, 2021, 1:37 p.m. UTC | #1
15/01/2021 14:26, Juraj Linkeš:
> A few options that disabled drivers in the old makefiles were improperly
> ported to the meson build system. Fix this by adding a to the list of

"by adding a" what?

> disabled drivers, similarly how the command line option works and remove
> unneeded driver options ported from the old makefile system, since they
> don't work in the current Meson build system.
> Add support for removing drivers for cross builds so that we can disable
> them in cross files.

Why disabling them?
If a driver is not supported it should disable itseld in its meson file.

[...]
> --- a/config/arm/arm64_armada_linux_gcc
> +++ b/config/arm/arm64_armada_linux_gcc
> @@ -18,3 +18,4 @@ implementer_id = '0x56'
>  part_number = '0xd08'
>  max_lcores = 16
>  max_numa_nodes = 1
> +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']

It's removing NXP drivers on Marvell SoC. Fine.
And what about other useless drivers?

> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> +# disable Arm drivers for all builds
> +disabled_drivers += ['net/avp', 'net/fm10k']

Why disabling avp and fm10k? Did they do something wrong to be banned?
Juraj Linkeš Jan. 19, 2021, 3:35 p.m. UTC | #2
+ Liron, Allain

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 18, 2021 2:37 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Cc: bruce.richardson@intel.com; Ruifeng.Wang@arm.com;
> Honnappa.Nagarahalli@arm.com; Phil.Yang@arm.com;
> vcchunga@amazon.com; Dharmik.Thakkar@arm.com; jerinjacobk@gmail.com;
> hemant.agrawal@nxp.com; ajit.khaparde@broadcom.com;
> ferruh.yigit@intel.com; aboyer@pensando.io; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 09/12] build: disable drivers in Arm builds
> 
> 15/01/2021 14:26, Juraj Linkeš:
> > A few options that disabled drivers in the old makefiles were
> > improperly ported to the meson build system. Fix this by adding a to
> > the list of
> 
> "by adding a" what?

This is a typo, the "a" should not be there. Would that be ok wording?

> 
> > disabled drivers, similarly how the command line option works and
> > remove unneeded driver options ported from the old makefile system,
> > since they don't work in the current Meson build system.
> > Add support for removing drivers for cross builds so that we can
> > disable them in cross files.
> 
> Why disabling them?
> If a driver is not supported it should disable itseld in its meson file.
> 

This is helpful when building for an SoC where we don't want to build to build a driver, but the build machine actually supports the driver. I believe in this case the meson build system would find the dependencies and designate the driver to be build, but we don't want to build the driver for that SoC.

There may be other reasons as well - Honnappa or others from the Arm community may shed more light on this.

> [...]
> > --- a/config/arm/arm64_armada_linux_gcc
> > +++ b/config/arm/arm64_armada_linux_gcc
> > @@ -18,3 +18,4 @@ implementer_id = '0x56'
> >  part_number = '0xd08'
> >  max_lcores = 16
> >  max_numa_nodes = 1
> > +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
> 
> It's removing NXP drivers on Marvell SoC. Fine.
> And what about other useless drivers?
> 

I only removed what was in the old Makefiles, so I don't really know. Liron or Jerin may be able to give us some insight.

> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > +# disable Arm drivers for all builds
> > +disabled_drivers += ['net/avp', 'net/fm10k']
> 
> Why disabling avp and fm10k? Did they do something wrong to be banned?
> 
> 
> 

This config is not only in the old Makefiles, but also in the current meson build system. I believe Jerin and Allain are the original authors, so they may be able to answer.
Liron Himi Jan. 19, 2021, 3:55 p.m. UTC | #3
-----Original Message-----
From: Juraj Linkeš <juraj.linkes@pantheon.tech> 
Sent: Tuesday, 19 January 2021 17:36
To: Thomas Monjalon <thomas@monjalon.net>
Cc: bruce.richardson@intel.com; Ruifeng.Wang@arm.com; Honnappa.Nagarahalli@arm.com; Phil.Yang@arm.com; vcchunga@amazon.com; Dharmik.Thakkar@arm.com; jerinjacobk@gmail.com; hemant.agrawal@nxp.com; ajit.khaparde@broadcom.com; ferruh.yigit@intel.com; aboyer@pensando.io; dev@dpdk.org; Liron Himi <lironh@marvell.com>; allain.legacy@windriver.com
Subject: [EXT] RE: [dpdk-dev] [PATCH v15 09/12] build: disable drivers in Arm builds

External Email

----------------------------------------------------------------------
+ Liron, Allain

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 18, 2021 2:37 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Cc: bruce.richardson@intel.com; Ruifeng.Wang@arm.com; 
> Honnappa.Nagarahalli@arm.com; Phil.Yang@arm.com; vcchunga@amazon.com; 
> Dharmik.Thakkar@arm.com; jerinjacobk@gmail.com; 
> hemant.agrawal@nxp.com; ajit.khaparde@broadcom.com; 
> ferruh.yigit@intel.com; aboyer@pensando.io; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 09/12] build: disable drivers in 
> Arm builds
> 
> 15/01/2021 14:26, Juraj Linkeš:
> > A few options that disabled drivers in the old makefiles were 
> > improperly ported to the meson build system. Fix this by adding a to 
> > the list of
> 
> "by adding a" what?

This is a typo, the "a" should not be there. Would that be ok wording?

> 
> > disabled drivers, similarly how the command line option works and 
> > remove unneeded driver options ported from the old makefile system, 
> > since they don't work in the current Meson build system.
> > Add support for removing drivers for cross builds so that we can 
> > disable them in cross files.
> 
> Why disabling them?
> If a driver is not supported it should disable itseld in its meson file.
> 

This is helpful when building for an SoC where we don't want to build to build a driver, but the build machine actually supports the driver. I believe in this case the meson build system would find the dependencies and designate the driver to be build, but we don't want to build the driver for that SoC.

There may be other reasons as well - Honnappa or others from the Arm community may shed more light on this.

> [...]
> > --- a/config/arm/arm64_armada_linux_gcc
> > +++ b/config/arm/arm64_armada_linux_gcc
> > @@ -18,3 +18,4 @@ implementer_id = '0x56'
> >  part_number = '0xd08'
> >  max_lcores = 16
> >  max_numa_nodes = 1
> > +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
> 
> It's removing NXP drivers on Marvell SoC. Fine.
> And what about other useless drivers?
> 

I only removed what was in the old Makefiles, so I don't really know. Liron or Jerin may be able to give us some insight.
[L.H.] In the past we had conflict with DPAA drivers, but recently we fixed it.
So no need for that anymore.

> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > +# disable Arm drivers for all builds disabled_drivers += 
> > +['net/avp', 'net/fm10k']
> 
> Why disabling avp and fm10k? Did they do something wrong to be banned?
> 
> 
> 

This config is not only in the old Makefiles, but also in the current meson build system. I believe Jerin and Allain are the original authors, so they may be able to answer.
Honnappa Nagarahalli Jan. 20, 2021, 1:11 a.m. UTC | #4
<snip>

> > 15/01/2021 14:26, Juraj Linkeš:
> > > A few options that disabled drivers in the old makefiles were
> > > improperly ported to the meson build system. Fix this by adding a to
> > > the list of
> >
> > "by adding a" what?
> 
> This is a typo, the "a" should not be there. Would that be ok wording?
> 
> >
> > > disabled drivers, similarly how the command line option works and
> > > remove unneeded driver options ported from the old makefile system,
> > > since they don't work in the current Meson build system.
> > > Add support for removing drivers for cross builds so that we can
> > > disable them in cross files.
> >
> > Why disabling them?
> > If a driver is not supported it should disable itseld in its meson file.
> >
> 
> This is helpful when building for an SoC where we don't want to build to build
> a driver, but the build machine actually supports the driver. I believe in this
> case the meson build system would find the dependencies and designate
> the driver to be build, but we don't want to build the driver for that SoC.
> 
> There may be other reasons as well - Honnappa or others from the Arm
> community may shed more light on this.
IMO, the assumption should be everything compiles on all the platforms. Hence, the disables should be applied to the platforms where the drivers do not compile.

> 
> > [...]
> > > --- a/config/arm/arm64_armada_linux_gcc
> > > +++ b/config/arm/arm64_armada_linux_gcc
> > > @@ -18,3 +18,4 @@ implementer_id = '0x56'
> > >  part_number = '0xd08'
> > >  max_lcores = 16
> > >  max_numa_nodes = 1
> > > +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
> >
> > It's removing NXP drivers on Marvell SoC. Fine.
> > And what about other useless drivers?
> >
> 
> I only removed what was in the old Makefiles, so I don't really know. Liron or
> Jerin may be able to give us some insight.
> 
> > > --- a/config/arm/meson.build
> > > +++ b/config/arm/meson.build
> > > +# disable Arm drivers for all builds disabled_drivers +=
> > > +['net/avp', 'net/fm10k']
> >
> > Why disabling avp and fm10k? Did they do something wrong to be banned?
> >
> >
> >
> 
> This config is not only in the old Makefiles, but also in the current meson
> build system. I believe Jerin and Allain are the original authors, so they may
> be able to answer.
Juraj Linkeš Jan. 22, 2021, 8:39 a.m. UTC | #5
> > > > disabled drivers, similarly how the command line option works and
> > > > remove unneeded driver options ported from the old makefile
> > > > system, since they don't work in the current Meson build system.
> > > > Add support for removing drivers for cross builds so that we can
> > > > disable them in cross files.
> > >
> > > Why disabling them?
> > > If a driver is not supported it should disable itseld in its meson file.
> > >
> >
> > This is helpful when building for an SoC where we don't want to build
> > to build a driver, but the build machine actually supports the driver.
> > I believe in this case the meson build system would find the
> > dependencies and designate the driver to be build, but we don't want to build
> the driver for that SoC.
> >
> > There may be other reasons as well - Honnappa or others from the Arm
> > community may shed more light on this.
> IMO, the assumption should be everything compiles on all the platforms. Hence,
> the disables should be applied to the platforms where the drivers do not
> compile.
> 

Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?
Thomas Monjalon Jan. 22, 2021, 8:58 a.m. UTC | #6
22/01/2021 09:39, Juraj Linkeš:
> > > > > disabled drivers, similarly how the command line option works and
> > > > > remove unneeded driver options ported from the old makefile
> > > > > system, since they don't work in the current Meson build system.
> > > > > Add support for removing drivers for cross builds so that we can
> > > > > disable them in cross files.
> > > >
> > > > Why disabling them?
> > > > If a driver is not supported it should disable itseld in its meson file.
> > > >
> > >
> > > This is helpful when building for an SoC where we don't want to build
> > > to build a driver, but the build machine actually supports the driver.
> > > I believe in this case the meson build system would find the
> > > dependencies and designate the driver to be build, but we don't want to build
> > the driver for that SoC.
> > >
> > > There may be other reasons as well - Honnappa or others from the Arm
> > > community may shed more light on this.
> > IMO, the assumption should be everything compiles on all the platforms. Hence,
> > the disables should be applied to the platforms where the drivers do not
> > compile.

If a driver does not compile, it can disable itself.
No need for a configuration.

> Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?

I think this patch should not disable drivers but just add the infra to do it.
Jerin Jacob Jan. 22, 2021, 9:07 a.m. UTC | #7
On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 22/01/2021 09:39, Juraj Linkeš:
> > > > > > disabled drivers, similarly how the command line option works and
> > > > > > remove unneeded driver options ported from the old makefile
> > > > > > system, since they don't work in the current Meson build system.
> > > > > > Add support for removing drivers for cross builds so that we can
> > > > > > disable them in cross files.
> > > > >
> > > > > Why disabling them?
> > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > >
> > > >
> > > > This is helpful when building for an SoC where we don't want to build
> > > > to build a driver, but the build machine actually supports the driver.
> > > > I believe in this case the meson build system would find the
> > > > dependencies and designate the driver to be build, but we don't want to build
> > > the driver for that SoC.
> > > >
> > > > There may be other reasons as well - Honnappa or others from the Arm
> > > > community may shed more light on this.
> > > IMO, the assumption should be everything compiles on all the platforms. Hence,
> > > the disables should be applied to the platforms where the drivers do not
> > > compile.
>
> If a driver does not compile, it can disable itself.
> No need for a configuration.
>
> > Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?
>
> I think this patch should not disable drivers but just add the infra to do it.

IMO, If the SOC has "fixed" set of dpdk devices, probably better to
have positive logic to enable only those in config file.
I think, that will be portable and useful.
IMO, We can have infrastructure code enable only specific drivers and
config owners can later enable the required set.

>
>
Thomas Monjalon Jan. 22, 2021, 10:19 a.m. UTC | #8
22/01/2021 10:07, Jerin Jacob:
> On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > disabled drivers, similarly how the command line option works and
> > > > > > > remove unneeded driver options ported from the old makefile
> > > > > > > system, since they don't work in the current Meson build system.
> > > > > > > Add support for removing drivers for cross builds so that we can
> > > > > > > disable them in cross files.
> > > > > >
> > > > > > Why disabling them?
> > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > >
> > > > >
> > > > > This is helpful when building for an SoC where we don't want to build
> > > > > to build a driver, but the build machine actually supports the driver.
> > > > > I believe in this case the meson build system would find the
> > > > > dependencies and designate the driver to be build, but we don't want to build
> > > > the driver for that SoC.
> > > > >
> > > > > There may be other reasons as well - Honnappa or others from the Arm
> > > > > community may shed more light on this.
> > > > IMO, the assumption should be everything compiles on all the platforms. Hence,
> > > > the disables should be applied to the platforms where the drivers do not
> > > > compile.
> >
> > If a driver does not compile, it can disable itself.
> > No need for a configuration.
> >
> > > Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?
> >
> > I think this patch should not disable drivers but just add the infra to do it.
> 
> IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> have positive logic to enable only those in config file.
> I think, that will be portable and useful.
> IMO, We can have infrastructure code enable only specific drivers and
> config owners can later enable the required set.

Yes you're right, enabling makes more sense than disabling for SoCs.
Honnappa Nagarahalli Jan. 25, 2021, 2:58 p.m. UTC | #9
<snip>

> 
> 22/01/2021 10:07, Jerin Jacob:
> > On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> > > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > > disabled drivers, similarly how the command line option
> > > > > > > > works and remove unneeded driver options ported from the
> > > > > > > > old makefile system, since they don't work in the current Meson
> build system.
> > > > > > > > Add support for removing drivers for cross builds so that
> > > > > > > > we can disable them in cross files.
> > > > > > >
> > > > > > > Why disabling them?
> > > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > > >
> > > > > >
> > > > > > This is helpful when building for an SoC where we don't want
> > > > > > to build to build a driver, but the build machine actually supports
> the driver.
> > > > > > I believe in this case the meson build system would find the
> > > > > > dependencies and designate the driver to be build, but we
> > > > > > don't want to build
> > > > > the driver for that SoC.
> > > > > >
> > > > > > There may be other reasons as well - Honnappa or others from
> > > > > > the Arm community may shed more light on this.
> > > > > IMO, the assumption should be everything compiles on all the
> > > > > platforms. Hence, the disables should be applied to the
> > > > > platforms where the drivers do not compile.
> > >
> > > If a driver does not compile, it can disable itself.
> > > No need for a configuration.
> > >
> > > > Would it be okay to leave the disabled as they're in this commit and
> leave the updates to the plaform owners? Thomas, what do you think?
> > >
> > > I think this patch should not disable drivers but just add the infra to do it.
> >
> > IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> > have positive logic to enable only those in config file.
> > I think, that will be portable and useful.
> > IMO, We can have infrastructure code enable only specific drivers and
> > config owners can later enable the required set.
> 
> Yes you're right, enabling makes more sense than disabling for SoCs.
Every SoC also supports PCIe interfaces. This means, one could use them with a PCIe based NIC (we do use these interfaces internally at Arm, I am not sure from a deployment perspective).

If we use the enable logic, the list will be huge?

>
Thomas Monjalon Jan. 25, 2021, 3:28 p.m. UTC | #10
25/01/2021 15:58, Honnappa Nagarahalli:
> > 22/01/2021 10:07, Jerin Jacob:
> > > On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net>
> > wrote:
> > > > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > > > disabled drivers, similarly how the command line option
> > > > > > > > > works and remove unneeded driver options ported from the
> > > > > > > > > old makefile system, since they don't work in the current Meson
> > build system.
> > > > > > > > > Add support for removing drivers for cross builds so that
> > > > > > > > > we can disable them in cross files.
> > > > > > > >
> > > > > > > > Why disabling them?
> > > > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > > > >
> > > > > > >
> > > > > > > This is helpful when building for an SoC where we don't want
> > > > > > > to build to build a driver, but the build machine actually supports
> > the driver.
> > > > > > > I believe in this case the meson build system would find the
> > > > > > > dependencies and designate the driver to be build, but we
> > > > > > > don't want to build
> > > > > > the driver for that SoC.
> > > > > > >
> > > > > > > There may be other reasons as well - Honnappa or others from
> > > > > > > the Arm community may shed more light on this.
> > > > > > IMO, the assumption should be everything compiles on all the
> > > > > > platforms. Hence, the disables should be applied to the
> > > > > > platforms where the drivers do not compile.
> > > >
> > > > If a driver does not compile, it can disable itself.
> > > > No need for a configuration.
> > > >
> > > > > Would it be okay to leave the disabled as they're in this commit and
> > leave the updates to the plaform owners? Thomas, what do you think?
> > > >
> > > > I think this patch should not disable drivers but just add the infra to do it.
> > >
> > > IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> > > have positive logic to enable only those in config file.
> > > I think, that will be portable and useful.
> > > IMO, We can have infrastructure code enable only specific drivers and
> > > config owners can later enable the required set.
> > 
> > Yes you're right, enabling makes more sense than disabling for SoCs.
> Every SoC also supports PCIe interfaces. This means, one could use them with a PCIe based NIC (we do use these interfaces internally at Arm, I am not sure from a deployment perspective).
> 
> If we use the enable logic, the list will be huge?

That's also right.
The last to talk will be right :)
Jerin Jacob Jan. 25, 2021, 4:09 p.m. UTC | #11
On Mon, Jan 25, 2021 at 8:28 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
>
> >
> > 22/01/2021 10:07, Jerin Jacob:
> > > On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net>
> > wrote:
> > > > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > > > disabled drivers, similarly how the command line option
> > > > > > > > > works and remove unneeded driver options ported from the
> > > > > > > > > old makefile system, since they don't work in the current Meson
> > build system.
> > > > > > > > > Add support for removing drivers for cross builds so that
> > > > > > > > > we can disable them in cross files.
> > > > > > > >
> > > > > > > > Why disabling them?
> > > > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > > > >
> > > > > > >
> > > > > > > This is helpful when building for an SoC where we don't want
> > > > > > > to build to build a driver, but the build machine actually supports
> > the driver.
> > > > > > > I believe in this case the meson build system would find the
> > > > > > > dependencies and designate the driver to be build, but we
> > > > > > > don't want to build
> > > > > > the driver for that SoC.
> > > > > > >
> > > > > > > There may be other reasons as well - Honnappa or others from
> > > > > > > the Arm community may shed more light on this.
> > > > > > IMO, the assumption should be everything compiles on all the
> > > > > > platforms. Hence, the disables should be applied to the
> > > > > > platforms where the drivers do not compile.
> > > >
> > > > If a driver does not compile, it can disable itself.
> > > > No need for a configuration.
> > > >
> > > > > Would it be okay to leave the disabled as they're in this commit and
> > leave the updates to the plaform owners? Thomas, what do you think?
> > > >
> > > > I think this patch should not disable drivers but just add the infra to do it.
> > >
> > > IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> > > have positive logic to enable only those in config file.
> > > I think, that will be portable and useful.
> > > IMO, We can have infrastructure code enable only specific drivers and
> > > config owners can later enable the required set.
> >
> > Yes you're right, enabling makes more sense than disabling for SoCs.
> Every SoC also supports PCIe interfaces. This means, one could use them with a PCIe based NIC (we do use these interfaces internally at Arm, I am not sure from a deployment perspective).

Not every SoC.

>
> If we use the enable logic, the list will be huge?

Yes. I think both support will be useful. IMO, Selecting a small
subset can be achieved via, have a flag in config file to disable all
the drivers and add the selective one as needed.

>
> >
>
diff mbox series

Patch

diff --git a/config/arm/arm64_armada_linux_gcc b/config/arm/arm64_armada_linux_gcc
index 2ecc4604c..e365f61d0 100644
--- a/config/arm/arm64_armada_linux_gcc
+++ b/config/arm/arm64_armada_linux_gcc
@@ -18,3 +18,4 @@  implementer_id = '0x56'
 part_number = '0xd08'
 max_lcores = 16
 max_numa_nodes = 1
+disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
diff --git a/config/arm/meson.build b/config/arm/meson.build
index d397471eb..c6eecd14c 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -2,6 +2,9 @@ 
 # Copyright(c) 2017 Intel Corporation.
 # Copyright(c) 2017 Cavium, Inc
 
+# disable Arm drivers for all builds
+disabled_drivers += ['net/avp', 'net/fm10k']
+
 # common flags to all aarch64 builds, with lowest priority
 flags_common = [
 	# Accelerate rte_memcpy. Be sure to run unit test (memcpy_perf_autotest)
@@ -16,9 +19,6 @@  flags_common = [
 	#	['RTE_ARM64_MEMCPY_ALIGN_MASK', 0xF],
 	#	['RTE_ARM64_MEMCPY_STRICT_ALIGN', false],
 
-	['RTE_NET_FM10K', false],
-	['RTE_NET_AVP', false],
-
 	['RTE_SCHED_VECTOR', false],
 	['RTE_ARM_USE_WFE', false],
 	['RTE_ARCH_ARM64', true],
@@ -130,7 +130,6 @@  implementer_cavium = {
 				['RTE_MACHINE', '"octeontx2"'],
 				['RTE_ARM_FEATURE_ATOMICS', true],
 				['RTE_USE_C11_MEM_MODEL', true],
-				['RTE_EAL_IGB_UIO', false],
 				['RTE_MAX_LCORE', 36],
 				['RTE_MAX_NUMA_NODES', 1]
 			]
diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
index 4e65b271c..210ad4508 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
@@ -143,3 +143,7 @@  There are other options you may specify in a cross file to tailor the build::
    Supported extra configuration
       max_numa_nodes = n  # will set RTE_MAX_NUMA_NODES
       max_lcores = n      # will set RTE_MAX_LCORE
+
+      disabled_drivers = ['bus/dpaa', 'crypto']  # add disabled drivers
+         # valid values are directories (optionally with their subdirs)
+         # in the drivers directory
diff --git a/drivers/meson.build b/drivers/meson.build
index f9febc579..c307929a4 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -18,9 +18,13 @@  subdirs = [
 	'baseband', # depends on common and bus.
 ]
 
-disabled_drivers = run_command(list_dir_globs, get_option('disable_drivers'),
+disabled_drivers += run_command(list_dir_globs, get_option('disable_drivers'),
 		).stdout().split()
 
+if meson.is_cross_build()
+	disabled_drivers += meson.get_cross_property('disabled_drivers', [])
+endif
+
 default_cflags = machine_args
 default_cflags += ['-DALLOW_EXPERIMENTAL_API']
 default_cflags += ['-DALLOW_INTERNAL_API']
diff --git a/meson.build b/meson.build
index 45d974cd2..fcc8931f0 100644
--- a/meson.build
+++ b/meson.build
@@ -21,6 +21,7 @@  dpdk_drivers = []
 dpdk_extra_ldflags = []
 dpdk_libs_disabled = []
 dpdk_drvs_disabled = []
+disabled_drivers = []
 abi_version_file = files('ABI_VERSION')
 
 if host_machine.cpu_family().startswith('x86')