[dpdk-dev] [PATCH v14 00/12] Arm build options rework

[Juraj Linkeš]

> -----Original Message-----
> From: Andrew Boyer <aboyer at pensando.io>
> Sent: Monday, January 4, 2021 11:46 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>
> Cc: thomas at monjalon.net; Juraj Linkeš <juraj.linkes at pantheon.tech>;
> bruce.richardson at intel.com; Ruifeng Wang <Ruifeng.Wang at arm.com>; Phil
> Yang <Phil.Yang at arm.com>; vcchunga at amazon.com; Dharmik Thakkar
> <Dharmik.Thakkar at arm.com>; jerinjacobk at gmail.com;
> hemant.agrawal at nxp.com; Ajit Khaparde (ajit.khaparde at broadcom.com)
> <ajit.khaparde at broadcom.com>; ferruh.yigit at intel.com; dev at dpdk.org; nd
> <nd at arm.com>
> Subject: Re: [dpdk-dev] [PATCH v14 00/12] Arm build options rework
> 
> 
> > On Jan 1, 2021, at 12:19 PM, Honnappa Nagarahalli
> <Honnappa.Nagarahalli at arm.com> wrote:
> >>
> >> 30/12/2020 20:09, Andrew Boyer:
> >>>
> >>>> On Dec 23, 2020, at 6:47 AM, Juraj Linkeš
> >>>> <juraj.linkes at pantheon.tech>
> >> wrote:
> >>>>
> >>>> The current way of specifying Arm configuration options is
> >>>> insufficient since we can't identify the SoC we're building for
> >>>> from the MIDR information. For example, we can't distinguish
> >>>> between N1SDP, Graviton2 or Ampere Altra.
> >>>>
> >>>> Add a way to specify the cpu count and numa node count for cross
> >>>> builds and aarch64 -> aarch64 (SoC) builds.
> >>>>
> >>>
> >>> Hello Juraj,
> >>> This is great, you have solved a problem for me before I even knew
> >>> there was one. (We have two SoCs with the same id and pn, but
> >>> different core counts etc.)
> >>>
> >>> Can anyone fill me in on how and when this patchset is going to be taken?
> >> Will it go to dpdk-next-net, or to some other branch?
> >>
> >> It should go in the main branch.
> >> I cannot commit on any date, but for sure it would help if you can do
> >> a detailed review, thanks.
> > Testing on your SoC would be of great help.
> >
> 
> Hello Honnappa, Juraj, and Bruce,
> 

Let me add my 2 cents.

> I've got most of the build working under meson. A few questions:
> 
> 1)  Bruce - when the “-Ddefault_library=both” flag is passed in, the build fails
> with this error. It’s been broken for a long time; maybe this option isn’t
> supported and should be blocked earlier?
> 
> 	../../dpdk/app/meson.build:48:3: ERROR: Tried to get unknown variable
> "both_rte_ethdev".
> 

This doesn't seem like an arm specific problem. I understand Bruce is already working on a patch, so won't do anything with this in this series.

> 2) Is there a way to disable specific libraries? I’ve pruned down the list of drivers,
> which is great. This feature existed under make but I don’t see anything about it
> in meson yet.
> 

We're missing an arch agnostic way to disable these, so there's no support for it in this series. When that exists we can use that to disable libs for arm socs.

There was some discussion about this in http://patches.dpdk.org/patch/78077/, but maybe there's more.

> 3) We need to build kni against the aarch64 kernel headers, but it fails. It
> appears that kernel/linux/kni/meson.build doesn’t pass any cross-compile flags
> in the make command it creates. The diff below shows how I hardcoded it to get
> it to work for now. Thoughts on how to do this right? meson has the path (in
> $PATH) and the binary prefixs (in ‘[binaries]’ in the cross file). It must know the
> arch, too.
> 
> --- a/kernel/linux/kni/meson.build
> +++ b/kernel/linux/kni/meson.build
> @@ -14,6 +14,8 @@ custom_target('rte_kni',
>         input: kni_sources,
>         output: 'rte_kni.ko',
>         command: ['make', '-j4', '-C', kernel_dir + '/build',
> +               'CROSS_COMPILE=/tool/toolchain/aarch64-1.1/bin/aarch64-linux-
> gnu-',
> +               'ARCH=aarch64',
>                 'M=' + meson.current_build_dir(),
>                 'src=' + meson.current_source_dir(),
>                 'MODULE_CFLAGS=-include ' + meson.source_root() +
> '/config/rte_config.h' +
> 

Yes, Meson should know these. I'll submit this separately (in a new series), as this series is getting pretty big and this fix is actually unrelated.

> I will try to get to a full review soon.
> 
> Thank you,
> Andrew