From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id 365225585 for ; Fri, 6 May 2016 13:46:46 +0200 (CEST) Received: from jvn (dynamic-109-81-211-84.ipv4.broadband.iol.cz [109.81.211.84]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3r1VP160pQzty; Fri, 6 May 2016 13:46:45 +0200 (CEST) Date: Fri, 6 May 2016 13:46:49 +0200 From: Jan Viktorin To: Declan Doherty Cc: Bruce Richardson , David Marchand , dev@dpdk.org, thomas.monjalon@6wind.com Message-ID: <20160506134649.5754c62b@jvn> In-Reply-To: References: <1454076516-21591-1-git-send-email-david.marchand@6wind.com> <1461152657-19969-1-git-send-email-david.marchand@6wind.com> <20160420120524.GA2020@bricha3-MOBL3> <20160420144118.16003a63@pcviktorin.fit.vutbr.cz> Organization: RehiveTech X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 11:46:46 -0000 Hello, On Fri, 6 May 2016 10:26:45 +0100 Declan Doherty wrote: > On 20/04/16 13:41, Jan Viktorin wrote: > > On Wed, 20 Apr 2016 13:05:24 +0100 > > Bruce Richardson wrote: > > > >> On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote: > >>> Following discussions with Jan [1] and some cleanup I started on pci code, > >>> here is a patchset that reworks pdev drivers registration and hotplug api. > >>> [...] > > The changes look good to me, nice to remove some of the duplication > ethdev/cryptodev. Yes, I like them too. > > Regarding enabling hot-plugging for crypto devices it looks like it > should be possible now to implement a mostly generic device > attach/detach functions, just with a simple wrapper to identify a > specific crypto or ethdev device structure. Do you have plans to do > this? If not, I can have a look as I would like to enable hot-plugging Yes. But, first I focused on the new SoC infra to find out what can be shared by the generic layer. I've got almost ready patch series, I will post it soon to the mailing list. It does not introduce the generic rte_driver/device yet, however, it shows that with [PATCH v2 00/17] prepare for rte_device / rte_driver it is now possible to do it quite easily. However, what I am not very sure about is whether we separate management of the PCI devices and SoC devices and any other such devices. Or whether we should have a single list for all. Second, the rte_driver must be removed from DPDK as it conflicts with the new rte_driver structure to be introduced. This should include removing of pmd_type, I think. I've expected that David M. will continue with v3 to move on (otherwise we'll get some merge conflicts I'd like to avoid). Another thing, there are structs like rte_pci_addr (etc.) which must (but I am not so sure) be probably generalized as well. And, devargs... Regards Jan > for crypto devices, without duplicating things that still reside in the > ethdev library at the moment. > -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic