From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gaetan.rivet@6wind.com> Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) by dpdk.org (Postfix) with ESMTP id 5C05F2BF5 for <dev@dpdk.org>; Mon, 26 Jun 2017 02:27:11 +0200 (CEST) Received: by mail-wr0-f177.google.com with SMTP id c11so131681321wrc.3 for <dev@dpdk.org>; Sun, 25 Jun 2017 17:27:11 -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=JEH0zYpCitVmdnHEbGmy35r5002IvkAv9LTKVrhIu3M=; b=ZvNmqoqUO9N6vPW+LQZWz6v0XvbP8GBzWd7P5HShT1InMddF7CLKCsg/BH1q0ztvxW jTE9jnEYsPNYavB8RdlZ4DgG5dz5Z3t+W5KNtoQc4059oNxAMfJbEawwdgKi162t7GW6 BaPdXukJNn1Yn/qULMZOtq01k0pP9MitJ/QCmb2lzJWiqihtW+qfsL/0af+2n6NJ+x1m LxvEyRI8CSliq2c3t50x+ax79JNjbPi3eF+7ppJUO8wLM2sbIuPg7RYBpe6kq6Se2Gn7 QzCI0hc0isVg3nOxiAipRF2BJv7z++I2XfO3FU40pKKgK8OQkSgHt2vJKy6+s5Eep6ni crbQ== 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=JEH0zYpCitVmdnHEbGmy35r5002IvkAv9LTKVrhIu3M=; b=OUD3DOSjtpnx0ny4svQykRrfckCHTYZqI2oOcVKc/F6KwC6seziQMGD51J/LVNp/bh bynIxH0rVdlkpvYt/KY0mvZW5zDYsQeX5b+5z1ctGf+wrCUe7xiojnAzLKWpjzPSoEP0 zrQNqwIWig9UrBeZgLwspMp0iWXbypEZvRPQYMBIAXu3DANf7tpx/k8lhjW4cVUgYMch u2U+RpRefPgpX2cWwvaZc+22g/r0QzUdkYtkpS9z+OicI8KWd+jT1k0eKW+9J/RZDhgY CfDI4gpgX/vXWKHzXcddP5JJWHRyZwhJuh6s9NcGPiYFrD11f1iQu2uAV388ibq8kv9O vYlQ== X-Gm-Message-State: AKS2vOyrYxzDlW5Tqu2WDI9U5AqJbt9JWALYR8DckUnGV5NRHlkGYM1t BJjwTaHGMpyaMMsj X-Received: by 10.28.18.201 with SMTP id 192mr11637918wms.2.1498436830546; Sun, 25 Jun 2017 17:27:10 -0700 (PDT) Received: from bidouze.vm.6wind.com ([62.23.145.78]) by smtp.gmail.com with ESMTPSA id l20sm8362407wre.25.2017.06.25.17.27.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jun 2017 17:27:09 -0700 (PDT) Date: Mon, 26 Jun 2017 02:27:02 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com> To: Stephen Hemminger <stephen@networkplumber.org> Cc: dev@dpdk.org, Jan Blunck <jblunck@infradead.org> Message-ID: <20170626002701.GK2344@bidouze.vm.6wind.com> References: <cover.1495637723.git.gaetan.rivet@6wind.com> <cover.1496235017.git.gaetan.rivet@6wind.com> <20170531083426.684e0e93@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170531083426.684e0e93@xeon-e3> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2 00/11] bus: attach / detach API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 26 Jun 2017 00:27:11 -0000 Hi Stephen, On Wed, May 31, 2017 at 08:34:26AM -0700, Stephen Hemminger wrote: > On Wed, 31 May 2017 15:17:45 +0200 > Gaetan Rivet <gaetan.rivet@6wind.com> wrote: > > > Following the work from Jan: > > > > This patchset introduces the attach / detach API to rte_bus. > > The rte_device structure is used as the generic device representation. > > > > This API is implemented for the virtual bus. > > The functions rte_eal_dev_attach and rte_eal_dev_detach are updated to > > use this new interface. > > > > -- > > > > 0. API rework > > ------------- > > > > I would like to propose an evolution on the API developed by Jan. > > > > The attach / detach rte_bus API is necessary to support the attach/detach > > rte_dev API. Those are two different levels for one similar functionality. > > > > Attach / detach does not allow true hotplugging, because the attach > > function expects the devices operated upon to already exist within the > > buses / sub-layers. This means that this API expects devices meta-datas > > (bus-internal device representation and associated device information > > read from the system) to be present upon attach. This part of the work > > is done during scanning. > > > > While it is best to avoid changing the public rte_dev API as it already > > exists, nothing prevents this new rte_bus API from superseeding it. > > It has been said during the previous release cycle that device hotplug > > was a feature that interested users. True hotplug is not allowed by the > > current attach / detach API. Worse, this API hinders the effort to bring > > this new functionality by squatting its semantic field. > > > > Thus, I propose to rename rte_bus attach / detach; plug / unplug. As it > > is a superset of the attach / detach functionality, it can be used to > > implement rte_dev attach / detach. Now is the right time to pivot to > > this new feature. > > > > This should help maintainers understanding the aim of this API and the > > differences with the APIs higher-up, clarify the field and allow a new > > functionality to be proposed. > > > > The vdev bus is inherently supporting the new API, however it has been > > made explicit. My implementation in the PCI bus in further patchset also > > follows the rte_bus hotplug API instead of only attach / detach. > > > > One remaining problem with the vdev bus is the rte_dev attach > > implementation, which needs the rte_devargs rework to be properly fixed. > > > > 1. Additional evolutions in the patchset > > ---------------------------------------- > > > > The RTE_VERIFY on the find_device is too stringent I think and forces > > all buses to implement a public device iterator. While it could be > > argued that it would push for quicker support for the functionality, I > > think it's possible that some buses are not interested at all in it and > > should simply be ignored. > > > > The bus devices iterator has been fixed. > > > > The internal rte_device handle was not properly setup within the > > net_ring PMD. > > > > Gaetan Rivet (2): > > vdev: implement hotplug functionality > > net/ring: fix dev handle in eth_dev > > > > Jan Blunck (9): > > bus: add bus iterator to find a particular bus > > bus: add device iterator > > bus: add helper to find bus for a particular device > > bus: add bus helper iterator to find a particular device > > bus: introduce hotplug functionality > > vdev: implement find_device bus operation > > vdev: implement unplug bus operation > > eal: make virtual driver probe and remove take rte_vdev_device > > ethdev: Use embedded rte_device to detach driver > > > > drivers/net/ring/rte_eth_ring.c | 7 ++ > > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 4 + > > lib/librte_eal/common/eal_common_bus.c | 65 +++++++++++++++ > > lib/librte_eal/common/eal_common_dev.c | 100 ++++++++++++++++++------ > > lib/librte_eal/common/eal_common_vdev.c | 27 +++++++ > > lib/librte_eal/common/include/rte_bus.h | 87 +++++++++++++++++++++ > > lib/librte_eal/common/include/rte_dev.h | 26 ++++++ > > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 + > > lib/librte_ether/rte_ethdev.c | 3 +- > > 9 files changed, 299 insertions(+), 23 deletions(-) > > > > LGTM > > Maybe we should evolve it by having both rte_bus and rte_dev API for one release and mark > the rte_dev API for attach/detach as deprecated? Sorry for the late response. I think that if the hotplug API is correctly designed, the rte_dev API could indeed be deprecated and then removed. I do not see a reason right now to keep it. -- Gaëtan Rivet 6WIND