From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id C86522904 for ; Mon, 12 Sep 2016 09:32:57 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id b187so121033440wme.1 for ; Mon, 12 Sep 2016 00:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wFckvbfe2refWLCb4mWDYMIAUaljbmAtkJGr6peK+mY=; b=qkMjIEzwpZHlEl/vNLrjaXZ8CBwU2W4+Kh8SH8CtDQVLuPy2lRLAgf32A8tWjCWvdZ nG0gUAIc9jpSJpoglhqtZOfGzQmhQqfnF9dY6IpLOTqk05MtwAEJiFc/wAIfUaO0ps5n jvw8dtVxS9GFYVvSejBd+Mr1jGHrdPOWOVZIrqtTm9CmiPWaeUzaf31Qlxy57Jhz9Bfr HqJ2ioSN0ASVVVHfnNkd1HAU7FSJJlAKFA2ZYyvGsKX2MZLY3IkmsDLHAW9YPCDcPAgL 02xRc60VkD5/sv796EKFLwxG/mrFZbQfN/ryXbhAGu8NT7TUSP94vsTpn8oj7r0VkZ6L gjIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wFckvbfe2refWLCb4mWDYMIAUaljbmAtkJGr6peK+mY=; b=EX5noLLldvPy8DbBG5S/+Vfoq2BbfrHW9BMC2crFLkk10SfDqt0ij6QuV8d1oxy6vC 2x9LD5Ott6xtBZFDRu4Xpe98pUP0MOvECTeYfigc7bvG+fCx8hTaR5S4W09mW8/SHicr YcIIl4bjR5xt/zJyHjEx45FAzfLO6XTFKv5NzNUTequ0McAAxXRZunqEmeK9HJvagghQ 6AoT8vKnYZaPOJ+GqMkCJAe4aFqhf7arBjKU6j1H/QVg82Gq4oHb3cXzX5ivv6/BDUDL g/68nDpef8rA5UuBvh/EpHM5sWpKvVSUbjuHwz4h6K2RVxVEhJ/EnmffC6GfVz4Nvtlq QV9w== X-Gm-Message-State: AE9vXwMOGN8ZaPUnxiuAQ5qho2bOMvEBYmuQ99eYNIJyR+IXgr9KlKauLSKzdZYv5y7GEUbswONRsCq87TLFYBKS X-Received: by 10.194.81.106 with SMTP id z10mr12919612wjx.140.1473665577597; Mon, 12 Sep 2016 00:32:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.97.213 with HTTP; Mon, 12 Sep 2016 00:32:36 -0700 (PDT) In-Reply-To: <1473257297-7221-1-git-send-email-shreyansh.jain@nxp.com> References: <1466510566-9240-1-git-send-email-shreyansh.jain@nxp.com> <1473257297-7221-1-git-send-email-shreyansh.jain@nxp.com> From: David Marchand Date: Mon, 12 Sep 2016 09:32:36 +0200 Message-ID: To: Shreyansh Jain Cc: "dev@dpdk.org" , hemant.agrawal@nxp.com Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH v9 00/25] Introducing rte_driver/rte_device generalization 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: Mon, 12 Sep 2016 07:32:58 -0000 Hello Shreyansh, On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain wrote: > This patch is part of larger aim to: > > --------------------+ > eth_driver (PMD) |-------------> rte_driver > crypto_driver (PMD) | ^ > | | > --------------------+ | > / > +-----------------------/+ > | rte_pci_driver | > | rte_vdev_driver | > | rte_soc_driver | > | rte_xxx_driver | > > Where PMD devices (rte_eth_dev, rte_cryptodev_dev) are connected to their > drivers rather than explicitly inheriting type specific driver (PCI, etc). > > > About the Patches: > ================== > > There are a large number of patches for this - primarily because the changes > are quite varied and keeping them logically separate yet compilable is > important. Most of the patches are small and those which are large touch the > drivers (PMDs) to accommodate the structure changes: > > - Patches 0001~0003 are for introducing the container_of function (so that > rte_device can be obtained from rte_pci_device, for example), and > removing unused code. > - Patches 0004~0007 just perform the ground work for enabling change from > rte_driver/eth_driver based PMDs to rte_xxx_driver based PMDs > - In patch 0008, all the pdev PMDs are changed to support rte_pci_driver ( > including cryptodev, which is eventually generalized with PCI) > - Patch 0009~0010 merge the crypto and pci functions for registration and > naming. > - Patches 0011~0014 deal with hotplugging - hotplug no more invokes scan of > complete bus and has been generalized into EAl from ethdev. > - Patches 0015 introduces vdev init/uninit into separate C units and > enables its compilation. Patch 0016~0017 build on it and remove the > remaining legacy support for vdev/pdev distinctions. > - Patches 0018~0022 enable the vdev drivers to register using the > DRIVER_REGISTER_* operations, and remove their rte_driver->init() > - Patch 0023 enables the rte_driver registration into a common driver > linked list. > - Patches 0024~0025 introduce the rte_device, a generalization of > rte_xxx_device, and associated operation of creating rte_device linked > list. It also enables the drivers to use rte_device.name/numa_node > members rather than rte_xxx_device specific members. > > Notes: > ====== > > * Some sign-off were already provided by Jan on the original v5; But, as a > large number of merges have been made, I am leaving those out just in case > it is not sync with initial understanding. > > * This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is > removed [7]. > > Future Work/Pending: > =================== > - Presently eth_driver, rte_eth_dev are not aligned to the rte_driver/ > rte_device model. eth_driver still is a PCI specific entity. This > has been highlighted by comments from Ferruh in [9]. > - cryptodev driver too still remains to be normalized over the rte_driver > model > - Some variables, like drv_name (as highlighted by Ferruh), are getting > duplicated across rte_xxx_driver/device and rte_driver/device. Overall, we are still missing some parts : - in my initial proposition, the rte_driver would embed the probe/remove (previsouly init/uninit) functions that would take rte_device object as arguments (and maybe we should get rid of the double lists, I am not yet convinced it is easy). - the pmdinfo stuff is broken and could be implemented for vdev, I did a quick patch that replaces the "PMD_REGISTER_DRIVER(.*)" regexp as "DRIVER_REGISTER_.*(.*)" then I added a DRIVER_EXPORT_NAME(nm, __COUNTER__) in the vdev register macro, it looks to work fine. pmdinfo is a bit too pci but I think we can go with this. - the names should go to rte_device/rte_driver objects ? -- David Marchand