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 <f...@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 <f...@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 > > >