Kernel Module dependency in DPDK 18.05-rc5 and earlier DPDK releases

Kernel Module dependency in DPDK 18.05-rc5 and earlier DPDK releases

[Kevin Wilson]

Hi,

I am facing the following issue in DPDK 18.05-rc5 (I saw it also with earlier
releases of DPDK from the last year). The issue is with defining
dependency on a kernel module in a PMD.
I want to develop a PMD which requiers that before running DPDK app which
uses this PMD, a specified kernel module is required to be insmoded.
I tried to add a call to RTE_PMD_REGISTER_KMOD_DEP in my PMD,
specifying a required
kernel module, and I expected that when calling a DPDK app which uses
this PMD it will shout that such a kernel module is not loaded, but this did not
happen.

So I took an existing kernel DPDK PMD (i40e), and I tried to add
dependency on the
link aggregation kernel module ("bonding.ko"). Again the same happened.

Am I missing something ?

I made two tries:
-RTE_PMD_REGISTER_KMOD_DEP(net_i40e, "* igb_uio | uio_pci_generic | vfio-pci");
+RTE_PMD_REGISTER_KMOD_DEP(net_i40e, "bonding");

And also
-RTE_PMD_REGISTER_KMOD_DEP(net_i40e, "* igb_uio | uio_pci_generic | vfio-pci");
+RTE_PMD_REGISTER_KMOD_DEP(net_i40e, "* bonding");

In both trials, I built the DPDK tree and ran testpmd, binding the i40e device
and using it with testpmd, and in both cases, bonding.ko was not loaded
(lsmod | grep bonding did not show anything).

In both cases, the testpmd app started OK, and no warning about
that bonding.ko was not loaded.

Any advise will be appreciated.

Regards,
KW

Re: Kernel Module dependency in DPDK 18.05-rc5 and earlier DPDK releases

[Thomas Monjalon]

25/05/2018 11:55, Kevin Wilson:
> Hi,
> 
> I am facing the following issue in DPDK 18.05-rc5 (I saw it also with earlier
> releases of DPDK from the last year). The issue is with defining
> dependency on a kernel module in a PMD.
> I want to develop a PMD which requiers that before running DPDK app which
> uses this PMD, a specified kernel module is required to be insmoded.
> I tried to add a call to RTE_PMD_REGISTER_KMOD_DEP in my PMD,
> specifying a required
> kernel module, and I expected that when calling a DPDK app which uses
> this PMD it will shout that such a kernel module is not loaded, but this did not
> happen.

No such check is implemented currently.
You can try to implement a check in EAL in the probing function.

Re: Kernel Module dependency in DPDK 18.05-rc5 and earlier DPDK releases

[Kevin Wilson]

Thanks, Thomas.

Actually there is an EAL rte_eal_check_module() method which does this exactly:
http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/eal.c#n1089
It is declared in eal_private.h.

Is it reasonable to send a patch which moves the decalartion to eal.h
instead so PMDs can use it in their probe() method ?

Apart from it -  So is there any practical effect for using the
RTE_PMD_REGISTER_KMOD_DEP() ? or is it only a sort of declarative
macro, saying that the PMD is dependent on the specified kernel
modules ? In the past - did it really ever check for dependency and
shouted back
when the required modules specified in the RTE_PMD_REGISTER_KMOD_DEP()
macro were not found ?

Regards,
KW


On Fri, May 25, 2018 at 2:21 PM, Thomas Monjalon <thomas@monjalon.net> wrote:
> 25/05/2018 11:55, Kevin Wilson:
>> Hi,
>>
>> I am facing the following issue in DPDK 18.05-rc5 (I saw it also with earlier
>> releases of DPDK from the last year). The issue is with defining
>> dependency on a kernel module in a PMD.
>> I want to develop a PMD which requiers that before running DPDK app which
>> uses this PMD, a specified kernel module is required to be insmoded.
>> I tried to add a call to RTE_PMD_REGISTER_KMOD_DEP in my PMD,
>> specifying a required
>> kernel module, and I expected that when calling a DPDK app which uses
>> this PMD it will shout that such a kernel module is not loaded, but this did not
>> happen.
>
> No such check is implemented currently.
> You can try to implement a check in EAL in the probing function.
>
>
>

Re: Kernel Module dependency in DPDK 18.05-rc5 and earlier DPDK releases

[Bruce Richardson]

On Fri, May 25, 2018 at 04:20:42PM +0300, Kevin Wilson wrote:
> Thanks, Thomas.
> 
> Actually there is an EAL rte_eal_check_module() method which does this exactly:
> http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/eal.c#n1089
> It is declared in eal_private.h.
> 
> Is it reasonable to send a patch which moves the decalartion to eal.h
> instead so PMDs can use it in their probe() method ?
> 
> Apart from it -  So is there any practical effect for using the
> RTE_PMD_REGISTER_KMOD_DEP() ? or is it only a sort of declarative
> macro, saying that the PMD is dependent on the specified kernel
> modules ? In the past - did it really ever check for dependency and
> shouted back
> when the required modules specified in the RTE_PMD_REGISTER_KMOD_DEP()
> macro were not found ?
> 
AFAIK this information is only used for reporting out when running pmdinfo
on a driver or statically linked binary. It was never enforced at runtime,
simply because the lack of particular ports was never an error. If a module
was not loaded, and NICs not bound to that module, it was always assumed
that the ports were never meant to be used by DPDK anyway.

/Bruce

Re: Kernel Module dependency in DPDK 18.05-rc5 and earlier DPDK releases

[Thomas Monjalon]

25/05/2018 15:57, Bruce Richardson:
> On Fri, May 25, 2018 at 04:20:42PM +0300, Kevin Wilson wrote:
> > Thanks, Thomas.
> > 
> > Actually there is an EAL rte_eal_check_module() method which does this exactly:
> > http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/eal.c#n1089
> > It is declared in eal_private.h.
> > 
> > Is it reasonable to send a patch which moves the decalartion to eal.h
> > instead so PMDs can use it in their probe() method ?
> > 
> > Apart from it -  So is there any practical effect for using the
> > RTE_PMD_REGISTER_KMOD_DEP() ? or is it only a sort of declarative
> > macro, saying that the PMD is dependent on the specified kernel
> > modules ? In the past - did it really ever check for dependency and
> > shouted back
> > when the required modules specified in the RTE_PMD_REGISTER_KMOD_DEP()
> > macro were not found ?
> > 
> AFAIK this information is only used for reporting out when running pmdinfo
> on a driver or statically linked binary. It was never enforced at runtime,
> simply because the lack of particular ports was never an error. If a module
> was not loaded, and NICs not bound to that module, it was always assumed
> that the ports were never meant to be used by DPDK anyway.

Yes it is informational.
But we can add a log to help with debug.
It could even be an error if a port is whitelisted.