dpdk: Add (partial) Kconfig support

[pprindeville]

Add support for a handful of Intel and AMD architectures, and some drivers.

[zokl]

Add support for a handful of Intel and AMD architectures, and some drivers.

Thank you for your PR. It's nice to have a choice of modules and components.

Do you try to compile libnuma for glibc and arm?

[pprindeville]

Add support for a handful of Intel and AMD architectures, and some drivers.

Thank you for your PR. It's nice to have a choice of modules and components.

Do you try to compile libnuma for glibc and arm?

I have not yet, no. If you have a .config you want me to test, mail it to me.

Just to clarify: are you wanting glibc and ARM tested together, or separately?

[zokl]

Add support for a handful of Intel and AMD architectures, and some drivers.

Thank you for your PR. It's nice to have a choice of modules and components. Do you try to compile libnuma for glibc and arm?

I have not yet, no. If you have a .config you want me to test, mail it to me.

Just to clarify: are you wanting glibc and ARM tested together, or separately?

Hi, I will check it this week. I want to test glibc only with x86_64. ARM only with musl. From my testing, there are some issues with using ARM with glibc.

[zokl]

@pprindeville, I have checked your PR, and I have several questions. Everything is only for x86_64. Do you plan to include ARM? The Makefile is now very long and unclear. I think a better way will be to input the menu structure to Config.in and MESON and MESON_ARGS more variables put to separate libdpdk.mk file and include it in the main Makefile. What do you think about it?

[pprindeville]

I don't have a problem with using a Config.in file. But having two separate Makefiles for the same tarball tends to be problematic. Usually all subpackages related to a tarball build in the same Makefile with multiple package definitions.

[zokl]

I don't have a problem with using a Config.in file. But having two separate Makefiles for the same tarball tends to be problematic. Usually all subpackages related to a tarball build in the same Makefile with multiple package definitions.

Why separate Makefile?

[pprindeville]

Oh, right, you did say to include it.

[zokl]

Oh, right, you did say to include it.

I am working on this PR based on your code https://github.com/k13132/openwrt-dpdk/blob/devel/packages/dpdk/libdpdk.mk x86_64 works but ARM is still in progress. What you think about it?

[pprindeville]

Okay, so I've added the Config.in file. It might even make sense to further split that into Config.in as the umbrella, then Config-x86_64.in, Config-aarch64.in, etc. if it gets too unmanageable.

Yes, I'm still working on ARM... need to figure out which platforms and drivers go with which platforms... there are many more than are actually applicable to OpenWrt, so I will end up dropping some.

Also, whereas the x86_64 target has a generic subtarget, we lack a homologue for aarch64 or arm64 or whatever in OpenWrt. I need to bring up this topic...

[zokl]

Okay, so I've added the Config.in file. It might even make sense to further split that into Config.in as the umbrella, then Config-x86_64.in, Config-aarch64.in, etc. if it gets too unmanageable.

Yes, I'm still working on ARM... need to figure out which platforms and drivers go with which platforms... there are many more than are actually applicable to OpenWrt, so I will end up dropping some.

Also, whereas the x86_64 target has a generic subtarget, we lack a homologue for aarch64 or arm64 or whatever in OpenWrt. I need to bring up this topic...

Thank you for your work.

For my project based on NXP is the main arm architecture aarch64. Now I am fighting with Openwrt meson wrapper and building generic platform :-(

[zokl]

Resolved in https://github.com/k13132/openwrt-dpdk/tree/arm