From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH v6 05/11] bus: introduce hotplug functionality Date: Fri, 30 Jun 2017 13:32:59 +0200 Message-ID: <20170630113259.GN13355@bidouze.vm.6wind.com> References: <14287370.n4WKZa6dWl@xps> <1765263.t0XI3ojoND@xps> <20170628153320.GA14672@bricha3-MOBL3.ger.corp.intel.com> <20170629125940.GL13355@bidouze.vm.6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Bruce Richardson , Thomas Monjalon , dev To: Jan Blunck Return-path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 946EF37A0 for ; Fri, 30 Jun 2017 13:33:08 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id 62so107548850wmw.1 for ; Fri, 30 Jun 2017 04:33:08 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jun 29, 2017 at 09:20:30PM +0200, Jan Blunck wrote: > On Thu, Jun 29, 2017 at 2:59 PM, Gaëtan Rivet wrote: > > What can be done to go forward: > > > > - Define the API for rte_bus interrupt sources, configuration and > > triggers to allow the development of the needed subsystems. > > > > - Each device event sources should offer an event parser to transform > > them in device descriptions. Depending on the specifics of the source, > > different levels of info are available. > > > > - Redefine the requirements for bus->scan() to allow hotplugging. > > > > - Reduce the scope of plug() from (scan-one + probe) to (probe), as > > everything is now in place. > > > > Also see the series that I send out today. From my point of view we > are here already. > Yes, your series is only a superficial departure from the v6. In the end, I see that your critics were pretty much only on interfaces and that you simply wanted it to be your way. You did not expose your reason for disagreeing, thus I threw a few ideas to at least make you either explicit your view or accept the current proposal. > > - Further hotplugging developments are then possible: add INTR_ADD > > support, with flexible device definition for example... A thing that > > is not yet possible with the current architecture but seemed to > > interest a few people. > > > > If we can agree that this is a way forward, do you think Jan that having > > the current plug() API hinders this plan? We can reduce its scope later, > > without changing current implementations as, as you said, a proper > > scan should be idempotent. The future API as envisionned is already > > respected, but right now the hotplug support in buses is a little more > > involved. Applications that will start using plug() right now would not > > have to be rewritten, as the requirements for plugging would still be > > fullfilled. > > > > We can support already hotplugging in DPDK. We can refine this support > > later to make it more generic and easier to implement for PMD > > maintainers. But I do not see this as a reason to block this support > > from being integrated right now. > > Indeed. I had hotplug support in the version of DPDK that I'm working > with for the last years. Don't get me wrong: I'm not arguing against > the inclusion of hotplug code. I just don't understand the reasoning > behind the implementation you proposed (with my original SOB) > especially since some of the things that you listed as going forward > are already there, are easy to fix or don't necessarily need to be > part of the DPDK EAL. > Don't get me wrong, I am not personally a proponent of these changes, but I wanted the current implementation to at least leave things open as I think a few people will push for this in a near future. But as far as I'm concerned, the hotplug support in DPDK will be sufficient in v17.08. > So lets try to get this right from the beginning. What is missing: > 1. document and verify that existing scan() implementations are idempotent > 2. example app with udev based hotplug > 3. check that the symbols are in the correct libraries (bus, pci, vdev) > > What am I missing? > Nothing on the technical side. -- Gaëtan Rivet 6WIND