On Thu, 5 Apr 2018 23:57:47 +0000
"Ananyev, Konstantin" <konstantin.anan...@intel.com> wrote:

> > -----Original Message-----
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Thursday, April 5, 2018 10:11 PM
> > To: Richardson, Bruce <bruce.richard...@intel.com>
> > Cc: Stephen Hemminger <sthem...@microsoft.com>; dev@dpdk.org; Stephen 
> > Hemminger <step...@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.

Reply via email to