DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: sothy shan <sothy.e98@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] No probed ethernet devices /DPDP 1.7.1 in Fedora 21
Date: Fri, 26 Dec 2014 09:37:37 -0500	[thread overview]
Message-ID: <20141226143737.GB5567@localhost.localdomain> (raw)
In-Reply-To: <CAHcF_0bjH=1F5NVCE5bzYuPTczOeRyEZsgrs4twP+Y0HYfxA5g@mail.gmail.com>

On Fri, Dec 26, 2014 at 09:01:13AM +0100, sothy shan wrote:
> On Thu, Dec 25, 2014 at 6:08 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> 
> > On Thu, Dec 25, 2014 at 10:11:51AM +0100, sothy shan wrote:
> > > On Wed, Dec 24, 2014 at 4:04 PM, Neil Horman <nhorman@tuxdriver.com>
> > wrote:
> > >
> > > > On Wed, Dec 24, 2014 at 02:26:21PM +0100, sothy shan wrote:
> > > > > Hello!
> > > > >
> > > > > I am playing with DPDK 1.7.1 in Fedora.
> > > > >
> > > > > When I do like this:
> > > > >
> > > > > export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
> > > > > make install T="$RTE_TARGET"
> > > > >
> > > > > It worked. Means Testpmd is running.
> > > > >
> > > > > When I run as mentioned below:
> > > > >
> > > > > make CONFIG_RTE_BUILD_SHARED_LIB=y  install T="$RTE_TARGET"
> > > > >
> > > > > Build is sucess. But Testpmd gives error.
> > > > >
> > > > > Error is :
> > > > >
> > > > The dpdk ivshmem build assumes the presence of ivshmem devices as
> > plumbed
> > > > by
> > > > qemu virtual guests.  If you don't have a qemu guest running dpdk won't
> > > > find any
> > > > shared memory devices, which is exactly what you are seeing.  That
> > said,
> > > > even if
> > > > you are running qemu guests, IIRC Fedora doesn't enable ivshmem because
> > > > the code
> > > > has some security and behavioral issues still I think.  You'll need to
> > > > rebuild
> > > > qemu to add support for it.
> > > >
> > >
> > > My understanding is that It is problem of enabling
> > > CONFIG_RTE_BUILD_SHARED_LIB=y in make command, I am able to build target
> > of
> > > x86_64-ivshmem-linuxapp-gcc alone without shared_lib flag. I suspect an
> > > error because of shared lib flag.
> > >
> > What exactly do you think that problem is?  You just said in your
> > origional note that you are able to build the sdk and test apps without
> > issue
> > (with or without building them as DSO's).  The problem comes in when you
> > run
> > the app, and I expect you get the same error with both static and dynamic
> > builds.
> >
> > The problem seems obvious to me.  DPDK cannot find any ivshmem devices on
> > your
> > system when it loads (look at the code in rte_eal_ivshmem_init).  The error
> > message you see gets output if you don't generate an ivshmem_config, which
> > happens (among a few other reasons), if you don't have any ivshmem devices
> > created on your system
> >
> > Neil
> >
> 
> 
> Do you have any hints for these messsages?
> 
Yes, I gave you direction in my last note, its the fact that no ivshmem devices
were found.

> EAL: Error - exiting with code: 1
>   Cause: No probed ethernet devices - check that
> CONFIG_RTE_LIBRTE_IGB_PMD=y and that CONFIG_RTE_LIBRTE_EM_PMD=y and that
> CONFIG_RTE_LIBRTE_IXGBE_PMD=y in your configuration file
> 
This is a false indicator.  If you look at a later version of the code you'll
see that the message has been pruned to just indicate that no probed ethernet
devices were found.  The remainder of the message was there because it used to
be a presumption that a physical devices was in use, which need not be the case.
Like I said before you need an ivshmem driver, which qemu provides, but not in
the current fedora build.

> 
> Is that with IVSHMEM device or physical devices? I guess it is physical
> device problem?
> 
No, its not, you're making this harder than it needs to be.  google qemu and
ivshmem and you'll see.  Heres an article to get you started:
http://lwn.net/Articles/380869/
Neil

> Thank you
> 
> Sothy

  reply	other threads:[~2014-12-26 14:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-24 13:26 sothy shan
2014-12-24 15:03 ` Masaru Oki
2014-12-24 15:04 ` Neil Horman
2014-12-25  9:11   ` sothy shan
2014-12-25 17:08     ` Neil Horman
2014-12-26  8:01       ` sothy shan
2014-12-26 14:37         ` Neil Horman [this message]
2015-01-09 16:20           ` sothy shan
2015-01-10 12:44             ` Neil Horman
2015-01-16 14:10               ` sothy shan
2015-01-16 14:27                 ` Olivier MATZ
2015-01-16 16:07                   ` sothy shan
2015-01-16 16:35                     ` Olivier MATZ
2015-01-16 16:47                       ` sothy shan

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=20141226143737.GB5567@localhost.localdomain \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=sothy.e98@gmail.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).