DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Alejandro Lucero <alejandro.lucero@netronome.com>,
	Flavio Leitner <fbl@redhat.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	dev <dev@dpdk.org>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	David Marchand <david.marchand@6wind.com>,
	jia.guo@intel.com, matan@mellanox.com, "Ananyev,
	Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [dpdk-dev] kernel binding of devices + hotplug
Date: Thu, 19 Apr 2018 11:47:40 +0200	[thread overview]
Message-ID: <2341963.L53P3Yzpy1@xps> (raw)
In-Reply-To: <20180419084044.GA11624@bricha3-MOBL.ger.corp.intel.com>

19/04/2018 10:40, Bruce Richardson:
> On Thu, Apr 19, 2018 at 10:24:24AM +0200, Thomas Monjalon wrote:
> > 19/04/2018 08:04, Alejandro Lucero:
> > > I do not completely understand the discussion, but I think the
> > > disagreement is due to how some devices interact with DPDK, at least
> > > Mellanox ones. I'm saying that because we have a DPDK app which starts
> > > with no device at all (--no-pci) and it relies on device plugging
> > > attach/detach for configuring and removing ports once devices are bound
> > > to VFIO or UIO drivers. Maybe I'm wrong, but I think because Mellanox
> > > cards do not use VFIO or UIO drivers but some specific bound using
> > > verbs inside the PMD, leaving all this binding to the system does not
> > > fit them.
> > 
> > Mellanox uses a bifurcated model for any use.  Others could use a
> > bifurcated model thanks to AF_XDP.  That's why it is more correct to
> > compare "bifurcated model" vs "UIO/VFIO".
> > 
> > > If that is the case, although I agree with leaving the device binding
> > > to the system, I think it would be fair to contemplate a dual approach
> > > for legacy reasons, or to leave time for implementing a pseudo system
> > > driver which Mellanox can use for having same functionality.
> > 
> > I summarize the comparison: - On one hand, we can configure all the
> > devices only once in DPDK, but it gives super-powers to the DPDK
> > application.  - On the other hand, we can do a part of the setup at
> > system level (some kernel binding or flow bifurcation), and we do another
> > part of the setup in DPDK, splitting/duplicating the setup info in two
> > places.
> > 
> I disagree with this final assessment. If there is duplication, it would
> appear more in the former case than in the latter, as the logic for
> determining driver binding and ownership would have to be duplicated in
> both the kernel and DPDK.  Also, there are plenty of instances where the
> kernel is going to use the devices without DPDK, so you can't reduce
> duplication by putting functionality into DPDK - the kernel is not going to
> remove functionality just because DPDK offers it! Therefore, if minimizing
> duplication is important to you, the solution to chose is to use as much
> from the kernel (and associated utilities like udev) as possible and not
> implement it in DPDK.

In any case, we need to choose and configure DPDK devices in DPDK
application, right?
If implementing all DPDK setup in DPDK, the only thing to do in system
config, is to NOT use the device (set IP, etc).
So preparing the devices for DPDK (or other userpace app) as part of the
system setup is an addition.

Note: I don't know which decision is better, I am just trying to think
about what the solutions are.

      reply	other threads:[~2018-04-19  9:47 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
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 [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=2341963.L53P3Yzpy1@xps \
    --to=thomas@monjalon.net \
    --cc=alejandro.lucero@netronome.com \
    --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=stephen@networkplumber.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).