From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 741A01CE28 for ; Fri, 6 Apr 2018 10:38:42 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 01:38:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,414,1517904000"; d="scan'208";a="39824541" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by FMSMGA003.fm.intel.com with SMTP; 06 Apr 2018 01:38:38 -0700 Received: by (sSMTP sendmail emulation); Fri, 06 Apr 2018 09:38:36 +0100 Date: Fri, 6 Apr 2018 09:38:36 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: "Ananyev, Konstantin" , Thomas Monjalon , Stephen Hemminger , "dev@dpdk.org" Message-ID: <20180406083836.GA89312@bricha3-MOBL.ger.corp.intel.com> References: <20180405191305.26813-1-sthemmin@microsoft.com> <1607753.vleKbttEpa@xps> <20180405210734.GA85168@bricha3-MOBL.ger.corp.intel.com> <1792191.Hreas2QKXW@xps> <2601191342CEEE43887BDE71AB977258A0AB9CCD@irsmsx105.ger.corp.intel.com> <20180405172242.5e63ac29@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180405172242.5e63ac29@xeon-e3> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH 2/3] usertools: add hv_uio_setup script X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:38:43 -0000 On Thu, Apr 05, 2018 at 05:22:42PM -0700, Stephen Hemminger wrote: > On Thu, 5 Apr 2018 23:57:47 +0000 > "Ananyev, Konstantin" 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 > > > Cc: Stephen Hemminger ; dev@dpdk.org; Stephen Hemminger > > > 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