Drivers, architectures, processor families, etc.

Drivers, architectures, processor families, etc.

[Philip Prindeville]

Hi,

I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.

Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.

Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.

Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?

Thanks,

-Philip

Re: Drivers, architectures, processor families, etc.

[Stephen Hemminger]

On Wed, 2 Aug 2023 15:49:54 -0600
Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:

> Hi,
> 
> I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.
> 
> Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.
> 
> Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.
> 
> Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?
> 
> Thanks,
> 
> -Philip
> 

DPDK now uses meson which by default builds everything available on the build architecture.
There is intentionally no way to disable drivers, you can disable some libraries though.

Re: Drivers, architectures, processor families, etc.

[Bruce Richardson]

On Wed, Aug 02, 2023 at 03:47:59PM -0700, Stephen Hemminger wrote:
> On Wed, 2 Aug 2023 15:49:54 -0600
> Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
> 
> > Hi,
> > 
> > I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.
> > 
> > Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.
> > 
> > Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.
> > 
> > Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?
> > 
> > Thanks,
> > 
> > -Philip
> > 
> 
> DPDK now uses meson which by default builds everything available on the build architecture.
> There is intentionally no way to disable drivers, you can disable some libraries though.

Actually, we do now support disabling drivers, and also only selectively
enabling specific ones. See disable_drivers and enable_drivers meson
options.

To find our different architecture support, I suggest looking in the config
directory. The subfolders there often contain cross-files for meson for
building for various architectures. For example, config/arm, contains a
number of reference files for cross-compiling for different arm platforms.

Regards,
/Bruce

Re: Drivers, architectures, processor families, etc.

[Philip Prindeville]

> On Aug 3, 2023, at 2:17 AM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> On Wed, Aug 02, 2023 at 03:47:59PM -0700, Stephen Hemminger wrote:
>> On Wed, 2 Aug 2023 15:49:54 -0600
>> Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
>> 
>>> Hi,
>>> 
>>> I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.
>>> 
>>> Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.
>>> 
>>> Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.
>>> 
>>> Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?
>>> 
>>> Thanks,
>>> 
>>> -Philip
>>> 
>> 
>> DPDK now uses meson which by default builds everything available on the build architecture.
>> There is intentionally no way to disable drivers, you can disable some libraries though.
> 
> Actually, we do now support disabling drivers, and also only selectively
> enabling specific ones. See disable_drivers and enable_drivers meson
> options.
> 
> To find our different architecture support, I suggest looking in the config
> directory. The subfolders there often contain cross-files for meson for
> building for various architectures. For example, config/arm, contains a
> number of reference files for cross-compiling for different arm platforms.
> 
> Regards,
> /Bruce


Noticed also that the ARM architecture has configs, but AMD64 seems to be wide open...  just one generic config.

Is that because some chips, like Xeon-D have on-die NICs, and others like Xeon-E don't?

-Philip

Re: Drivers, architectures, processor families, etc.

[Bruce Richardson]

On Sat, Aug 05, 2023 at 03:32:37PM -0600, Philip Prindeville wrote:
> 
> 
> > On Aug 3, 2023, at 2:17 AM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> > 
> > On Wed, Aug 02, 2023 at 03:47:59PM -0700, Stephen Hemminger wrote:
> >> On Wed, 2 Aug 2023 15:49:54 -0600
> >> Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
> >> 
> >>> Hi,
> >>> 
> >>> I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.
> >>> 
> >>> Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.
> >>> 
> >>> Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.
> >>> 
> >>> Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?
> >>> 
> >>> Thanks,
> >>> 
> >>> -Philip
> >>> 
> >> 
> >> DPDK now uses meson which by default builds everything available on the build architecture.
> >> There is intentionally no way to disable drivers, you can disable some libraries though.
> > 
> > Actually, we do now support disabling drivers, and also only selectively
> > enabling specific ones. See disable_drivers and enable_drivers meson
> > options.
> > 
> > To find our different architecture support, I suggest looking in the config
> > directory. The subfolders there often contain cross-files for meson for
> > building for various architectures. For example, config/arm, contains a
> > number of reference files for cross-compiling for different arm platforms.
> > 
> > Regards,
> > /Bruce
> 
> 
> Noticed also that the ARM architecture has configs, but AMD64 seems to be wide open...  just one generic config.
> 
> Is that because some chips, like Xeon-D have on-die NICs, and others like Xeon-E don't?
> 

Its just that folks generally don't cross-compile for x86, and also the
fact that nobody has ever brought it up before. We have no "native-build"
files in DPDK, only cross-files for cross-compilation. However, if there is
demand for them no reason we can't store some.

/Bruce

Re: Drivers, architectures, processor families, etc.

[Philip Prindeville]

> On Aug 8, 2023, at 2:17 AM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> On Sat, Aug 05, 2023 at 03:32:37PM -0600, Philip Prindeville wrote:
>> 
>> Noticed also that the ARM architecture has configs, but AMD64 seems to be wide open...  just one generic config.
>> 
>> Is that because some chips, like Xeon-D have on-die NICs, and others like Xeon-E don't?
>> 
> 
> Its just that folks generally don't cross-compile for x86, and also the
> fact that nobody has ever brought it up before. We have no "native-build"
> files in DPDK, only cross-files for cross-compilation. However, if there is
> demand for them no reason we can't store some.
> 
> /Bruce


We bought a Mac Studio (fully configured) for doing in-house CI/CD, and it was beating the pants off of any of our Xeon servers, so now we build everything either on an M2 Mac or on a Graviton EC2 instance.

Native builds are overrated. :-)

-Philip

Re: Drivers, architectures, processor families, etc.

[Philip Prindeville]

> On Aug 2, 2023, at 4:47 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> On Wed, 2 Aug 2023 15:49:54 -0600
> Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
> 
>> Hi,
>> 
>> I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.
>> 
>> Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.
>> 
>> Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.
>> 
>> Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?
>> 
>> Thanks,
>> 
>> -Philip
>> 
> 
> DPDK now uses meson which by default builds everything available on the build architecture.
> There is intentionally no way to disable drivers, you can disable some libraries though.



The issue I'm trying to resolve is that if you're building for SoC Xyzzy that includes an on-chip NIC, then that driver should *only* ever be selectable when building for that SoC.

There's no point if generating (or packaging) combinations of platform + driver that aren't viable.

Are you suggesting that we just select the architecture, and let the available drivers fall out of that?

Re: Drivers, architectures, processor families, etc.

[Bruce Richardson]

On Thu, Aug 03, 2023 at 10:40:47AM -0600, Philip Prindeville wrote:
> 
> 
> > On Aug 2, 2023, at 4:47 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> > 
> > On Wed, 2 Aug 2023 15:49:54 -0600
> > Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
> > 
> >> Hi,
> >> 
> >> I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.
> >> 
> >> Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.
> >> 
> >> Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.
> >> 
> >> Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?
> >> 
> >> Thanks,
> >> 
> >> -Philip
> >> 
> > 
> > DPDK now uses meson which by default builds everything available on the build architecture.
> > There is intentionally no way to disable drivers, you can disable some libraries though.
> 
> 
> 
> The issue I'm trying to resolve is that if you're building for SoC Xyzzy that includes an on-chip NIC, then that driver should *only* ever be selectable when building for that SoC.
> 
> There's no point if generating (or packaging) combinations of platform + driver that aren't viable.
>
Actually, for development purposes there is good reason. By having e.g. NIC
drivers for ARM SoCs be built when doing an x86 build, it allows us to
catch changes that break that driver. It also allows one to do a generic
build where the one build could be used across multiple platforms.

/Bruce

Re: Drivers, architectures, processor families, etc.

[Ferruh Yigit]

On 8/2/2023 10:49 PM, Philip Prindeville wrote:
> Hi,
> 
> I'm trying to come up with some Kconfig logic for OpenWRT packaging to help users select the right build options for their hardware.
> 
> Most OpenWRT developers typically cross-compile, so we obviously can't rely on detection on the build host as that's rarely the same as the target machine.
> 
> Looking in the DPDK repo, I don't see any description of the available architectures, drivers, etc. and what I had seen previously was (if I remember) only for x86_64 hardware, and even that I can't seem to locate again.
> 
> Would it make sense to put some of these definitions into the repo itself, so that when new drivers are added, that stands out (at least in the commit logs) and we can capture the permutations of what driver goes with which SoC on what architecture, etc?
> 

Hi Philip,

DPDK builds x86 architecture as natively, and rest (arm, ppc, riscv, ..)
as cross compile and doesn't select drivers based on architecture but
tries to build as much driver as possible.

But there is an OS based filtering, like some drivers are disabled if
the build OS is Windows or FreeBSD etc..

As most of the devices are external devices, unlike on-chip devices in
SoC, it make sense to build them into final binary.


Still there are on-chip devices, or there are combinations that some
devices can't be used in an architecture but still included, to NOT have
a finer granularity here helps DPDK binary distributions also helps
build testing.

There are meson build options to limit which driver to built in or not,
if there is a specific embedded platform target and if binary size
matters, these arguments can be used.
But we don't have a generic config or logic that can be used for OpenWRT
builds.

Thanks,
ferruh