Re: [dpdk-dev] kernel binding of devices + hotplug

[Thomas Monjalon <thomas@monjalon.net>]

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.