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

[Bruce Richardson <bruce.richardson@intel.com>]

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.