DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] IGB_UIO port unbinding
Date: Fri, 11 Apr 2014 09:24:35 -0700	[thread overview]
Message-ID: <20140411092435.29e06974@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <C6ECDF3AB251BE4894318F4E451236975927405D@IRSMSX104.ger.corp.intel.com>

On Thu, 10 Apr 2014 09:39:35 +0000
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> Hi everyone
> 
> As you may or may not know, the CONFIG_RTE_EAL_UNBIND_PORTS was deprecated in the official Intel(r) DPDK 1.6.0 release package. However, the code itself (e.g. in lib/librte_eal/linuxapp/eal_pci.c and other places) to support that config option was not removed. My question would be, would anyone be opposed to a patch to remove that code entirely? E.g. does anyone use that functionality?
> 
> Best regards,
> Anatoly Burakov
> DPDK SW Engineer

I actually liked the unbind code that was there. It meant that additional logic
did not have to be added to the startup script to do PCI discovery and finding/mapping
devices.

As it is the EAL startup process is a bit of a mess. It assumes that various
bits of information and infrastructure are already in place prior to starting
the DPDK application.

Other silly DPDK environment issues are: why does DPDK have to know the number
of memory channels in the system? How is the end user of an application supposed
to know this? Sure your hacker might but not end user. It is difficult to impossible
to determine this information at runtime. The best I could find is to use DMI decode
to count number of memory banks and guess!

The CPU mask is also something that should "do the right thing" and use all CPU's
unless told otherwise. Having to wrap every DPDK application in a shell script
makes the application more brittle and creates overlapping effort.

  parent reply	other threads:[~2014-04-11 16:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10  9:39 Burakov, Anatoly
2014-04-10 11:39 ` Thomas Monjalon
2014-04-10 16:04   ` Prashant Upadhyaya
2014-04-11  8:43     ` Thomas Monjalon
2014-04-11  8:59     ` Burakov, Anatoly
2014-04-11  9:06       ` Prashant Upadhyaya
2014-04-11  9:19         ` Burakov, Anatoly
2014-04-11 16:24 ` Stephen Hemminger [this message]
2014-04-14  8:57   ` Burakov, Anatoly
2014-04-14 15:33     ` Stephen Hemminger
2014-04-14 15:40       ` Burakov, Anatoly

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=20140411092435.29e06974@nehalam.linuxnetplumber.net \
    --to=stephen@networkplumber.org \
    --cc=anatoly.burakov@intel.com \
    --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).