From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=CLtz1X8/PCjLVqyG5Vf34Ss87vwf+zT76ZorLyAP7BU=; b=eRVg5b3s/I0plyw8XBM2okgD4tAtVwibAz/vuzKTuL0Y3FohQE0XrCgNXy8hcjHQYy pu7ehHMr6lAfjkR5tbqJ3T+OrKuDsx7Mz0d5Mghw2Z08B+cAkU+TZSuGSvlcrRiQQQPf bQdOxnB+liIOeHadgkx+icUyuXWbzIMSx/W/8dL9ZU4MtpN72Ui8Gyst+4KJ/lRPMfTM nScVAX67RVYyIEYS+jj3NSeR6yjfJTtQSttksfXCXsNiCKeQTP6Tcz7Ss80Bdg8cwMrU +ibErWSjCB15a0cxrQ8tsE+NaWhutGQ6k3hB1Lg0uSOqAQ/yxsILDwyx9P7aprXOs2e/ ChqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=CLtz1X8/PCjLVqyG5Vf34Ss87vwf+zT76ZorLyAP7BU=; b=lVqfSwV8r0j3sKc7xIAGasEMQsF00q5uBdkJc5TLWZJw/lYUek7v461xnXNkb0emNx 90kF1eDdDHzwBtDYpKRUCJRfOvmLEgN9hAH0w4A8htip6GkPsrDwNeCVFhIWfw87xbmV x9Pu2BlqBjyL6DU09kAmmyVAJIp0cOT66ALz0lBnlejlmxv6ml8QyDrfFnvkPzVVPL2+ 9h5WdGWh3ne7137xK0u4TV/ANJKadIjQ+e8xRyXIQsRVxhFluVPwUSYxpJeHfhhRA5gR kiPXsi1SRHEeqnoY0lPVb+HWBrWfxDIOS1fmaDBSGBN2ljv5UlyYtbkehmgJw6MCkfjV AO5Q== X-Gm-Message-State: AIVw112gOXS1hVkAKQH5cO1ELL51cN2W6B7t/SudK6ZmlPr+0JO9IcpB KCJp+vVhP6QXfwC3 X-Received: by 10.28.95.130 with SMTP id t124mr1314014wmb.115.1498822388181; Fri, 30 Jun 2017 04:33:08 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id w197sm12590508wme.20.2017.06.30.04.33.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 04:33:07 -0700 (PDT) Date: Fri, 30 Jun 2017 13:32:59 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Jan Blunck Cc: Bruce Richardson , Thomas Monjalon , dev 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v6 05/11] bus: introduce hotplug functionality 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, 30 Jun 2017 11:33:08 -0000 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