From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com [209.85.192.174]) by dpdk.org (Postfix) with ESMTP id 712017CCD for ; Wed, 31 May 2017 17:34:30 +0200 (CEST) Received: by mail-pf0-f174.google.com with SMTP id n23so12247981pfb.2 for ; Wed, 31 May 2017 08:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=MSjumkJfJbkrKMTjsfHSxR7Mx3JBxk0ySRhseCaGQ9Q=; b=XobX3iwXyb2mKhlUwUYbkQkevKcM2cQnJXudGL+KkZahqCnizOrkh0ufudXrkJmtae lZccz/9MQmKU/ebq3uFIaLFJ3I3NUE6KAQ9znzchP7cpMgyGrabb0On04D0stbYXyO4P IrDGvEvNhChGIfiAC6idVYo5a9xS7edqzU0ndO8ZdQnCMEfSvYAYl09yZAjsKFntPhaj mHSF0oRJ+eNxiyY6Jl74KXPQ/sR0qVp2qiRI6/M3lTsYIeG+XbJhsXub07XS5Whh8FyR dV1dx6Eg+lSaMVJoqBBFrySMGrTyFspcyNtu2Mlj+zg42dK7wi9u8xEAlxaYxoxdZ3/c N4Hg== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=MSjumkJfJbkrKMTjsfHSxR7Mx3JBxk0ySRhseCaGQ9Q=; b=q0c+eg4epsiFiaqVXw5w+JWUeWmztyLCASojU0Ft2yap7UShr1QVNMr10l7yV7uJMq ENgyGybs3RKdw4Lzgj+NMIyLbWoKPbxPefRPDUXUulzOh/FFkTg6FwGZAdXfrCmciipu yTGfAFGuLo3eRStO4+GS8wS+PI2DVQsMH2UQfWx+GmEYdGfpchGP3v4KSnKgWu94aUXc J6hRJM0HvN56vXe9N8dp9RAXMxbvFVWS1AKbLSrqZOhGiXTCLJsThbmhqf6u5/UJNpzt xwGH8ZXHziDrP9VMf7ORWHlx409CShUZPLUgqdGzu2CsjhAVNeUmqRYdb/WSppz57qut 8B7w== X-Gm-Message-State: AODbwcBRW+FD0UPq+1qI/ew1eZ4r8QMuPesnPdf8TdKL38wpWIpNagmq p28Ahqy7+xemmN3VeY0QNw== X-Received: by 10.98.209.22 with SMTP id z22mr29938909pfg.95.1496244869570; Wed, 31 May 2017 08:34:29 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id a87sm33435926pfj.50.2017.05.31.08.34.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 31 May 2017 08:34:29 -0700 (PDT) Date: Wed, 31 May 2017 08:34:26 -0700 From: Stephen Hemminger To: Gaetan Rivet Cc: dev@dpdk.org, Jan Blunck Message-ID: <20170531083426.684e0e93@xeon-e3> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 15:34:30 -0000 On Wed, 31 May 2017 15:17:45 +0200 Gaetan Rivet 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?