From: Stephen Hemminger <stephen@networkplumber.org>
To: Matan Azrad <matan@mellanox.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>,
Thomas Monjalon <thomas@monjalon.net>,
"dev@dpdk.org" <dev@dpdk.org>,
"pmatilai@redhat.com" <pmatilai@redhat.com>,
"david.marchand@6wind.com" <david.marchand@6wind.com>,
"jia.guo@intel.com" <jia.guo@intel.com>,
"konstantin.ananyev@intel.com" <konstantin.ananyev@intel.com>,
"fbl@redhat.com" <fbl@redhat.com>
Subject: Re: [dpdk-dev] kernel binding of devices + hotplug
Date: Mon, 16 Apr 2018 09:57:23 -0700 [thread overview]
Message-ID: <20180416095723.0d7698c7@xeon-e3> (raw)
In-Reply-To: <AM4PR0501MB26573CEAC80A0B71C24422C1D2B00@AM4PR0501MB2657.eurprd05.prod.outlook.com>
On Mon, 16 Apr 2018 16:11:12 +0000
Matan Azrad <matan@mellanox.com> wrote:
> > If the device management is only managed in one place, i.e. not in DPDK,
> > then there is no conflict to manage.
>
> I can't agree with this statement,
> The essence of DPDK is to give a good alternative to managing network devices,
> DPDK actually takes a lot of management area to manage by itself to do the user life better :)
More is not better! DPDK is poorly integrated into Linux overall system. Doing
more in DPDK makes this worse not better.
Buried under this discussion is the fact that the Mellanox bifurcated driver
behaves completely differently from every other driver. This makes coming to
a common solution much harder. The bifurcated model has advantages and disadvantages,
in this case it is a disadvantage since it is not easy to manage usage when
it is a shared resource.
next prev parent reply other threads:[~2018-04-16 16:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-13 16:31 Thomas Monjalon
2018-04-13 16:40 ` Bruce Richardson
2018-04-13 17:40 ` Burakov, Anatoly
2018-04-14 20:10 ` Matan Azrad
2018-04-16 8:31 ` Bruce Richardson
2018-04-16 16:11 ` Matan Azrad
2018-04-16 16:57 ` Stephen Hemminger [this message]
2018-04-16 17:10 ` Matan Azrad
2018-04-16 17:18 ` Stephen Hemminger
2018-04-16 17:32 ` Matan Azrad
2018-04-16 17:50 ` Thomas Monjalon
2018-04-17 9:23 ` Ananyev, Konstantin
2018-04-17 10:42 ` Matan Azrad
2018-04-17 11:00 ` Ananyev, Konstantin
2018-04-22 11:26 ` Matan Azrad
2018-04-16 9:26 ` Guo, Jia
2018-04-16 16:11 ` Matan Azrad
2018-04-15 5:01 ` Wiles, Keith
2018-04-15 1:48 ` Stephen Hemminger
2018-04-18 14:11 ` Flavio Leitner
2018-04-18 18:17 ` Stephen Hemminger
2018-04-18 18:54 ` Flavio Leitner
2018-04-19 6:04 ` Alejandro Lucero
2018-04-19 8:24 ` Thomas Monjalon
2018-04-19 8:40 ` Bruce Richardson
2018-04-19 9:47 ` Thomas Monjalon
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=20180416095723.0d7698c7@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=fbl@redhat.com \
--cc=jia.guo@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=matan@mellanox.com \
--cc=pmatilai@redhat.com \
--cc=thomas@monjalon.net \
/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).