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: Mon, 14 Apr 2014 08:33:03 -0700 [thread overview]
Message-ID: <20140414083303.09cb43ed@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <C6ECDF3AB251BE4894318F4E451236975927DC44@IRSMSX101.ger.corp.intel.com>
On Mon, 14 Apr 2014 08:57:54 +0000
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> Hi Stephen,
>
> > 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.
>
> I would argue that it's not the responsibility of the application to set up its environment. The EAL startup process is indeed a bit all over the place, but the alternative would be worse. Those "various bits of information and infrastructure" you're referring to include, say, hugepages - I don't think it's a good idea for an application to meddle with system's hugepages any more than I think it's a good idea for it to meddle with the driver bindings.
>
> Plus, current state of affairs makes for headaches in the future when support for other drivers is implemented (say, VFIO). It's much better to move the responsibility of binding the drivers to the user, and DPDK provides quite convenient means to do that (the PCI binding Python script) and also a centralized script to prepare the DPDK environment without much hassle (the setup.sh).
>
> Best regards,
> Anatoly Burakov
> DPDK SW Engineer
>
The problem is that doing the initialization requires duplicating all the
logic to probe the PCI bus and do blacklisting etc in the startup application.
next prev parent reply other threads:[~2014-04-14 15:33 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
2014-04-14 8:57 ` Burakov, Anatoly
2014-04-14 15:33 ` Stephen Hemminger [this message]
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=20140414083303.09cb43ed@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).