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

[Thomas Monjalon <thomas@monjalon.net>]

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.


> On Wed, Apr 18, 2018 at 7:54 PM, Flavio Leitner <fbl@redhat.com> wrote:
> > On Wed, Apr 18, 2018 at 11:17:47AM -0700, Stephen Hemminger wrote:
> > > On Wed, 18 Apr 2018 11:11:01 -0300
> > > Flavio Leitner <fbl@redhat.com> wrote:
> > > > On Sun, Apr 15, 2018 at 01:48:36AM +0000, Stephen Hemminger wrote:
> > > > > My vote is to work with udev and not try to replace it.
> > > > >
> > > > > Driverctl works well. Just not for bifurcated driver
> > > >
> > > > I second that.  We also have other system configs to care about like
> > > > kernel parameters and hugepage configuration which I think follow the
> > > > same idea that they are system wide configs and should not be managed
> > > > by DPDK itself.
> > >
> > > Maybe teach driverctl (and udev) to handle bifurcated drivers.
> >
> > I don't know the challenges to tech driverctl to handle bifurcated
> > drivers but I would agree that it should be our first place to look at.
> >
> > > Unfortunately, vendors are very fractured on how network devices are
> > managed.
> >
> > You mean distros? hw vendors? all vendors? :)
> >
> > Perhaps if community focus on something, then they might follow at some
> > point.
> >
> > --
> > Flavio
> >
>