Re: [dpdk-dev] [PATCH 2/3] usertools: add hv_uio_setup script

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

On Thu, Apr 05, 2018 at 05:22:42PM -0700, Stephen Hemminger wrote:
> On Thu, 5 Apr 2018 23:57:47 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> 
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > > Sent: Thursday, April 5, 2018 10:11 PM
> > > To: Richardson, Bruce <bruce.richardson@intel.com>
> > > Cc: Stephen Hemminger <sthemmin@microsoft.com>; dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>
> > > Subject: Re: [dpdk-dev] [PATCH 2/3] usertools: add hv_uio_setup script
> > > 
> > > 05/04/2018 23:07, Bruce Richardson:  
> > > > On Thu, Apr 05, 2018 at 10:43:39PM +0200, Thomas Monjalon wrote:  
> > > > > 05/04/2018 21:13, Stephen Hemminger:  
> > > > > > Small script to rebind netvsc kernel device to Hyper-V
> > > > > > networking PMD. It could be integrated in dpdk-bind, but dpdk-bind
> > > > > > is focused on PCI, and that would get messy.
> > > > > >
> > > > > > Eventually, this functionality will be built into netvsc driver
> > > > > > (see vdev_netvsc as an example).  
> > > > >
> > > > > I believe we should avoid creating such script.
> > > > > The direction to go, for hotplug, is to remove dpdk-devbind.py,
> > > > > and implement kernel binding in PMDs (with EAL helpers).
> > > > >  
> > > > I'm not convinced at all that that is the direction to go. I instead would
> > > > prefer to see all binding happen outside DPDK. I believe having udev or
> > > > similar manage bindings, set up via e.g driverctl[1], is a far better path.  
> > > 
> > > This is a system admin tool, and only for Linux.
> > > Having the binding logic inside DPDK, allows the application to control
> > > how hotplug behave.  
> > 
> > I also don't think that DPDK application should control hotplug behavior logic.
> > It is clearly up to the system admin to make such decisions. 
> > Konstantin
> 
> My preference would be to get driverctl working as a standard tool.
> But it requires kernel changes to work with vmbus.
> 
+1

I don't think that binding should be done by DPDK for a couple of reasons:
1. There are already daemons and kernel supports out there, such as udev,
   for managing devices on a system level. I'd rather not see DPDK duplicate
   functionality, when we can re-use what is there. Also there exists the
   possibility of conflict, e.g. what if udev has a rule for a device, and
   DPDK also tries to manage it at the same time.

2. I believe that the app is the wrong place to manage the binding of
   devices, since it's up to the system administrator not the app to determine
   the exact setup for the platform. If apps are to manage binding, then each
   app will have to expose to the user/sysadmin cmdline options to specify
   what devices should be hotplugged into the app or not, and what drivers
   they should be bound too. Not all NICs hotplugged to a platform are for
   DPDK use, and they won't all want to use the igb_uio or the vfio_pci
   drivers. Better that that is configured for each platform on the platform
   itself.

I really feel that the driverctl approach is the best one - yes it's linux
only for now, but architecturally I think it's the proper solution.

/Bruce