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 BC37D5580 for ; Fri, 15 Jul 2016 17:34:35 +0200 (CEST) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3rrc7b3Y4Qz6l0; Fri, 15 Jul 2016 17:34:35 +0200 (CEST) Date: Fri, 15 Jul 2016 17:33:59 +0200 From: Jan Viktorin To: Thomas Monjalon Cc: Shreyansh Jain , David Marchand , dev@dpdk.org Message-ID: <20160715173359.4bc0eb25@pcviktorin.fit.vutbr.cz> In-Reply-To: <1803983.1lZj4rVXKI@xps13> References: <20160708190945.24225-1-viktorin@rehivetech.com> <1803983.1lZj4rVXKI@xps13> Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v1 00/15] rte_driver/device infrastructure 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, 15 Jul 2016 15:34:35 -0000 On Fri, 15 Jul 2016 15:19:14 +0200 Thomas Monjalon wrote: > 2016-07-08 21:09, Jan Viktorin: > > Hello, > > > > based on the discussions with Shreyansh, I propose a patchset with > > the important EAL changes. It is incomplete and I suppose to extend > > and change certain things in the foreseeable future. > > > > Important notes: > > > > * pmd_type is removed > > * introduced rte_vdev_driver inheriting rte_driver > > * PMD_REGISTER_DRIVER is replaced by RTE_EAL_VDRV_REGISTER > > * rte_driver/device integrated into rte_pci_driver/device > > * all drivers and devices are in 2 lists - general and bus-specific > > > > Shreyansh, I hope I do not duplicate your work. I tried to avoid touching > > pmd_type but it quite complicated... There is also an initial generalization > > of rte_pci_resource. More such generalizations are to be done. > > > > The init/uninit functions cannot be generalized easily, I think. Both PCI > > and VDEV have different requirements. > > > > No idea about hotplug... > > Please could you give a clear overview of how you split the work in > your respective series? Yes, it's a bit messy... My quick summary follows. > > I take the opportunity to put my notes about some initial targets of > this refactoring: > > module/drivers > attached to 1 bus: pci_driver or vdev_driver pci_driver is done by Shreyansh/David vdev_driver is done by myself > rte_device = device resources / embedded in pci/vdev_driver Extraction of rte_device is done by myself > attached to n device interfaces (ethdev, crypto) > 1 device resource -> n device interfaces I am not sure, what those two points means exactly. > hotplug resource -> lookup drivers list > per-bus lists or 1 list? Not sure. At least partially done by Shreyansh/David. > devinit/devuninit generalized and moved to rte_driver > -> rename to probe/remove Some renames done by Shreyansh/David. There will be no move. The vdev_driver has different kind of init/uninit then PCI. So I cannot see a simple way how to generalize this. I'll do the final init->probe, uninit->remove renames. > crypto.dev_type could be dropped I am not sure about this. > drv_flags should be moved to rte_driver I'll do. > intr_init can be moved earlier in init, before affinity set > devices Done by Shreyansh/David. > unique_device_name -> standard naming? Done for PCI: rte_eal_pci_device_name by Shreyansh/David. > difference with port_id ? -> device id for ethdev Not sure. > should be unique_resource_name -> 1 EAL resource may match several devices Not sure. > ethdev manage an interface, eal manage a hardware resource, device object in between? Not sure about the question. > need for bus object? I don't think so at this stage. > no need of driver object, module object? The current rte_driver will not exist. Same for any kind of module. > devargs, intr_handle, numa_node should be moved to rte_device Yes, done by myself. > hotplug notification to do > notify free-able ressource? > remove blacklist at EAL level and let application handle it > devargs still in hotplug function, must be moved in separate API > devargs > new API > new command line parameters > -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic