dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: bugzilla@dpdk.org
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [Bug 333] PCI devices not found when DPDK is linked as dynamic libraries
Date: Fri, 19 Jul 2019 16:17:24 -0700	[thread overview]
Message-ID: <20190719161724.20789f1b@hermes.lan> (raw)
In-Reply-To: <bug-333-3@http.bugs.dpdk.org/>

On Fri, 19 Jul 2019 20:43:04 +0000
bugzilla@dpdk.org wrote:

> https://bugs.dpdk.org/show_bug.cgi?id=333
> 
>             Bug ID: 333
>            Summary: PCI devices not found when DPDK is linked as dynamic
>                     libraries
>            Product: DPDK
>            Version: 19.08
>           Hardware: All
>                 OS: Linux
>             Status: UNCONFIRMED
>           Severity: critical
>           Priority: Normal
>          Component: core
>           Assignee: dev@dpdk.org
>           Reporter: stephen@networkplumber.org
>   Target Milestone: ---
> 
> If DPDK is configured with RTE_SHARED_LIB=y then applications are not loading
> the required PCI library and therefore devices are not found.
> 
> Example is that l3fwd works if linked statically but fails if built with shared
> libraries.
> 
> # ./examples/l3fwd/build/l3fwd -n4 -l0-3 -w 02:00.0
> EAL: Detected 8 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: failed to parse device "02:00.0"
> EAL: Unable to parse device '02:00.0'
> EAL: Error - exiting with code: 1
>    Cause: Invalid EAL parameters  
> 
> The string 02:00.0 should have been parsed by PCI library and that will find
> the device. but since library is not pulled in, the device is not found.
> 

There are two levels of problems here.

#1 All the bus drivers work by registering themselves in the bus subsystem.
But with the --as-needed flag the RTE_INIT() that registers is not run on
PCI (or other bus) when built as shared library. This is resolved by flag
changes in mk.rteapp.mk.

#2 All the PMD drivers have the same problem. Even though they get built,
their RTE_INIT does not get called either since they are not on the application
link line.

#3 Similar problems with mempools.

Not sure if the real answer is to always link application with the
libdpdk.so (combined group) instead of the laundry list of libraries.

Lastly, why is shared library build not tested as part of the CI
infrastructure?

      reply	other threads:[~2019-07-19 23:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19 20:43 [dpdk-dev] [Bug 333] PCI devices not found when DPDK is linked as dynamic libraries bugzilla
2019-07-19 23:17 ` Stephen Hemminger [this message]

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=20190719161724.20789f1b@hermes.lan \
    --to=stephen@networkplumber.org \
    --cc=bugzilla@dpdk.org \
    --cc=dev@dpdk.org \
    /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).