DPDK patches and discussions
 help / color / mirror / Atom feed
From: Keunhong Lee <dlrmsghd@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Can not init NIC after merge to DPDK 1.7 problem
Date: Thu, 25 Sep 2014 17:02:28 +0900	[thread overview]
Message-ID: <CAKBXKmD_w9ybbNOnGA8qP-gUfWKoZPYQGqxC-bwu45ECVk=PJg@mail.gmail.com> (raw)
In-Reply-To: <20140923191213.GE12884@hmsreliant.think-freely.org>

In DPDK1.7, PMDs are loaded by __constructor__ functions.
As there is no direct reference to each PMD driver structures, linker may
not link the PMD library.
You should use -Wl,--whole-archive and -Wl,--no-whole-archive for linking
DPDK applications.
See http://dpdk.org/browse/dpdk/tree/mk/rte.app.mk for further information.

Keunhong.



2014-09-24 4:12 GMT+09:00 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
>
>

  reply	other threads:[~2014-09-25  7:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23 18:53 Wang, Shawn
2014-09-23 19:12 ` Neil Horman
2014-09-25  8:02   ` Keunhong Lee [this message]
2014-09-23 20:03 ` Matthew Hall
2014-09-23 21:50 Sanford, Robert
2014-09-23 23:17 ` Wang, Shawn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKBXKmD_w9ybbNOnGA8qP-gUfWKoZPYQGqxC-bwu45ECVk=PJg@mail.gmail.com' \
    --to=dlrmsghd@gmail.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).