Re: [dpdk-dev] Can not init NIC after merge to DPDK 1.7 problem

[Neil Horman <nhorman@tuxdriver.com>]

On Tue, Sep 23, 2014 at 06:53:57PM +0000, Wang, Shawn wrote:
> Hi:
> 
> We are using our own Makefile in building dpdk program. Recently we are working on upgrading from DPDK 1.3 to DPDK 1.7. I found the rte_ixgbe_pmd_init has been replaced by PMD_REGISTER_DRIVER. So I delete rte_ixgbe_pmd_init calls. But after that, our dpdk program could not correctly find the NIC anymore. After digging into it a little more, I found the code dose not correctly register the driver type we are using, which is ixgbe.
> To isolate the problem, I hacked a smal example l3fwd, and only have the main.c file like this for my testing purpose.
> 
> #include <rte_config.h>
> #include <rte_eal.h>
> 
> #include "main.h"
> 
> int
> MAIN(int argc, char **argv)
> {
>         /* init EAL */
>         int ret = rte_eal_init(argc, argv);
>         printf("ret %d\n", ret);
>         return 0;
> }
> 
> I found if I use the Makefile provided in the example, the program will find the ixgbe NIC. But if I just use these 2 commands to compile and link it. It will not find the ixgbe NIC.
> 
> gcc -I../../x86_64-native-linuxapp-gcc/include -L../../x86_64-native-linuxapp-gcc/lib -lrte_eal -c main.c
> gcc -o l3fwd main.o -L../../x86_64-native-linuxapp-gcc/lib -lrte_eal -lrte_distributor -lrte_pipeline -lrte_port -lrte_timer -lrte_hash -lrte_acl -lm -lrt -lrte_mbuf -lethdev -lrte_malloc -lrte_mempool -lrte_ring -lc -lm -lrte_cmdline -lrte_cfgfile -lrte_pmd_bond -lrte_pmd_ixgbe -lrte_pmd_e1000 -lrte_pmd_ring -lpthread -ldl -lrt
> 
> Can someone share some light on what is magic of the dpdk Makefile to correctly register the NIC type?
> 
> Thank you so much.
> Xingbo Wang
> 

I'm not really sure why you would strip out the Makefiles to dpdk, but I suppose
thats not the germaine question.

First, how are you building the DPDK?  As a set of shared libraries, or as a set
of static archives?  If you're building shared libraries, you need to pass
-shared to gcc, or the constructors will get stripped out using your command
line above.  There might be some other options that escape me, but you can find
out for sure by using the packaged makefiles and running make V=1 to see all the
passed options in the link stage

Secondly, when you say register the NIC type, do you mean that you don't see the
NIC get registered with dpdk, or you don't see an instance of the NIC created?
If its the former, you need to confirm that by running a debugger and looking at
what elements are on the device_list after your applications starts.  If its the
latter, that may well be a config error, as you may need to pass the --whitelist
option on the command line to trigger a device probe.

Neil