From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) by dpdk.org (Postfix) with ESMTP id 580B629CA for ; Thu, 29 Jun 2017 21:20:31 +0200 (CEST) Received: by mail-wr0-f176.google.com with SMTP id k67so193638085wrc.2 for ; Thu, 29 Jun 2017 12:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=GunlNtmNG3AougpR+NRmWUIVhmg54NwMd37aS9oYmEs=; b=cSzr9vPViXYOvDfA6TK7GJQFRZAItjKajXsuhcfv0njBKrD6/I0UCsgZLuVkBw+onG YcvdJVJF2HxUiMlPvpBSpg6Awrzzj0VLkZap0NVCtAucO4Z2cbQTWXsxYoMtzkQJ4Wkl o2Lpo+0lWyzaSJf8PJJWjZM8ClC7LtEPM/05NPbmbR/jgBHLWx9CtxMBZRyqhPd+Hw2F gFug7khbOpWurNPBQUllGciyLN9v15IjHmtk2TP9eJzyOMSic283s26tIWdMbw4a2LXu ulR2a17Wm/id5wBWUp16k+PmV3yb/zCA7vyIInRbiJNrY66fp6TcjqIHWTUTtBI63nz6 bkEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=GunlNtmNG3AougpR+NRmWUIVhmg54NwMd37aS9oYmEs=; b=hb3pQ35fgljaxLn1PsCkhYQmS2OY0saHpWu6uxESH7unETlvqU1Mu0EAM8tG1SJIHn oEdAQCvuDVfvoQQtBzOte17igu3ozq0Osr7gZutKh7BM2iPfFkxNAATOU+EcAOj78yVF 4WfOzZr4g7XpcfC2LtkCRtF5e8Jr+i+xVRoMJSDXo+5NEzqcPUbqaZKh6ukziNyVO97x 6Yi2drjy85/uspls5wxA+LsXg/blQSdyas+/heItyipduXrZreTWiGRmKB3bXnoZPr2X SvvxYftw7Yavo5bZ2XyX2iMd1x9B9wOa+4d7rMmrAYa/9obpwCy18reo9FkIRPPeEWCH bFYQ== X-Gm-Message-State: AKS2vOwv6t97Wq15WlWLiTQ+crIfiEVacMY0NcnbMrvsDkyAey3ty4Qd jUFQxsEAmzHhbmHsu9abgrQoS1ztjw== X-Received: by 10.223.182.172 with SMTP id j44mr18715805wre.122.1498764030899; Thu, 29 Jun 2017 12:20:30 -0700 (PDT) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.5.136 with HTTP; Thu, 29 Jun 2017 12:20:30 -0700 (PDT) In-Reply-To: <20170629125940.GL13355@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> From: Jan Blunck Date: Thu, 29 Jun 2017 21:20:30 +0200 X-Google-Sender-Auth: fcWUPYFUeCivkdJqhyMOxyd-hIE Message-ID: To: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= Cc: Bruce Richardson , Thomas Monjalon , dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 29 Jun 2017 19:20:31 -0000 On Thu, Jun 29, 2017 at 2:59 PM, Ga=C3=ABtan Rivet = wrote: > > Hi all, > > We are all for having "true" hotplug support in DPDK. > By true hotplug, it means that at some point, a new device exists on the > system, while the DPDK bus on which it should be probed does not yet > have its metadata. Something needs to be done to retrieve these metadata, > one way or another. > > What I see as a solution to this: > > - An interrupt framework integrated to rte_bus, allowing drivers to > describe interrupt sources (Kernel UEVENT, custom FDs, ...), to their > buses. > > - Applications should be able to pilot these interrupts for rte_bus > (either in describing expected devices, or allowing actions to be > taken upon device removal). > > - Buses could take the responsibility of plugging in and out their own > devices, once properly configured. > This is highly application dependent and it is up to the application developer to decide when such events are getting processed. There is a major difference between the data path functionality that support interrupts and the processing of hotplug events. So from my perspective it needs to be left as an exercise to the programmer to add the polling of the /sysfs files into the event loop. We might offer an example of how to do this though. > In this context, it is possible to imagine triggering a bus-rescan upon > device ADD, iff we explicitly define scan() as being idempotent (a thing > that is not part of its API yet and that we cannot expect from buses at > this point). Hmm, so from what I can tell the PCI bus offers an idempotent scan() and if I haven't added any bugs this is true for the virtual bus too. > Then, we can limit bus->plug() to a probe, once we are sure that > metadatas for the bus are (almost) always in sync with the system. > > Where we are: > > - Intel is proposing a UEVENT API[1]. It might be interesting to help the= m > make it respect a generic framework. Just because you can do it and someone invested time doesn't mean its a good idea. What problem is this solving? You now have a DPDK native library that reads uevents ... Where is the benefit for the application developer? Although we replicate some components of an operating system in userspace it doesn't mean that we are building one. If we don't push back on things that don't belong here we will have a big pile of average code soon instead of focusing on the technical problems that need to get addressed. > - A first plug / unplug implementation is being proposed. Plug() is > currently effectively defined as (scan-one + probe). > > 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. > - 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. 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? > [1]: http://dpdk.org/ml/archives/dev/2017-June/069057.html > > -- > Ga=C4=97tan Rivet > 6WIND