[Buildroot] [PATCH v5] dpdk: new package

Jan Viktorin viktorin at rehivetech.com
Tue Apr 19 12:27:44 UTC 2016


Hello Arnout,

thanks for your comments...

On Tue, 19 Apr 2016 00:50:27 +0200
Arnout Vandecappelle <arnout at mind.be> wrote:

> On 04/18/16 10:23, Jan Viktorin wrote:
> > On Sun, 17 Apr 2016 23:06:07 +0200
> > Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:
> >  
> >> Hello,
> >>
> >> On Sun, 17 Apr 2016 22:56:07 +0200, Jan Viktorin wrote:
> >>  
> [snip]
> >>> Ok. I don't know what would be the use case for dropping dependency
> >>> on the kernel. Building just the rootfs without the kernel?  
> >>
> >> For example, yes. Another benefit of not having the mandatory kernel
> >> dependency is that the autobuilders would be able to test the DPDK
> >> package.  
> >
> > I have no clue about this. Does kernel dependency prevent some
> > auto-testing?  
> 
>   The base configs used in the autobuilders don't include a kernel (or 
> bootloader or rootfs). Therefore, any package depending on the kernel is never 
> built.
> 
>   We _could_ actually add a couple of base configs that do include a kernel. But 
> someone has to do it :-)

I have no idea how to access the autobuilder nor what kind of complexity
is connected with this...

> 
> >  
> >>  
> >>> That means to check whether the kernel is enabled. And if it is then
> >>> to enable building of the DPDK kernel modules. Right?  
> >>
> >> Correct.  
> >
> > I would implement this in Buildroot by a list of configuration keys
> > naming certain drivers. If the kernel is disabled, I'd disable all of
> > them during configure phase. Otherwise, I'd leave them untouched (to
> > have the current configuration as is). So, I'd put in dpdk.mk
> > something like:
> >
> > ifeq ($(BR2_LINUX_KERNEL),y)
> > DPDK_DEPENDENCIES += linux
> > else
> > DPDK_KMODS = EAL_IGB_UIO KNI_KMOD LIBRTE_XEN_DOM0
> >
> > define DPDK_DISABLE_KMODS
> > $(foreach m,$(DPDK_KMODS),\  
> 
>   Small nit: indent with tab here.

OK, it was just an ad hoc example. I'd rather know whether I can implement it this way.

> 
> > 	$(call KCONFIG_DISABLE_OPT,CONFIG_RTE_$(m),$(@D)/build/.config))
> > endef
> >
> > DPDK_POST_CONFIGURE_HOOKS += DPDK_DISABLE_KMODS  
> 
>   Is dpdk using Kconfig? In that case, please use the kconfig-package infra. It 
> gives you simple primitives for disabling and enabling options. Consult the manual.

Unfortunately, there is no kconfig. It just looks this way. The buildsystem is custom.

> 
> > endif
> >
> > Probably, I can improve it by testing whether a module is present
> > in the DPDK config and then setting the dependency on linux.  
> 
>   That's not possible: DEPENDENCIES must be declared when the makefiles are 
> parsed, but the tarball containing .config is only extracted afterwards.

OK, it was just an idea.

Regards
Jan

> 
> 
>   Regards,
>   Arnout
> 
> >
> > Anyway, it seems to be quite complex...
> >  
> >>  
> >>> This can be done but I am afraid I have to disable certain modules by
> >>> name from the current configuration. This is not very generic
> >>> (consider adding a new out-of-tree kernel module or removing an
> >>> obsolete one from the DPDK, custom DPDK tree with third party
> >>> modules) but there are only few of them so it might be a working
> >>> solution. I will check if there is a more generic way but I don't
> >>> think so.  
> >>
> >> I'm not sure what you mean here. If the default configuration on a
> >> given architecture builds kernel modules, then on this architecture,
> >> DPDK should depend on the kernel to be built. If the default
> >> configuration on another architecture does not build kernel modules,
> >> then there is no need to depend on the kernel.
> >>
> >> That being said, if only ARM does not build any kernel module, maybe we
> >> can simply do as you do right now, and depend on the kernel
> >> unconditionally, to keep things simple.  
> >
> > Yes, this would work for the existing defconfigs. What about a custom
> > one? E.g. I want some DPDK kernel modules for the Armada with a
> > PCI-E NIC. So, I need a custom DPDK configuration at the moment.
> > Fortunately, this is a rare case.
> >
> > There is also a Xen module in DPDK that is not built by default so you
> > have to create a custom configuration (or alter an existing one) to
> > enable it.
> >
> > I understand that you'd like to keep it as simple as possible. I'd like
> > to keep it simple too but also providing enough flexibility for easy
> > customizations. That's why I don't consider the ARMv7 configuration to
> > be "without kernel modules" as it is possible to enable some if needed.  
> 
> 
> 



-- 
   Jan Viktorin                  E-mail: Viktorin at RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic


More information about the buildroot mailing list