From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0068.outbound.protection.outlook.com [104.47.32.68]) by dpdk.org (Postfix) with ESMTP id 8A90B8E64 for ; Thu, 8 Sep 2016 09:03:29 +0200 (CEST) Received: from DM2PR03CA0022.namprd03.prod.outlook.com (10.141.96.21) by MWHPR03MB2447.namprd03.prod.outlook.com (10.169.200.141) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Thu, 8 Sep 2016 07:03:27 +0000 Received: from BN1BFFO11FD047.protection.gbl (2a01:111:f400:7c10::1:127) by DM2PR03CA0022.outlook.office365.com (2a01:111:e400:2428::21) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9 via Frontend Transport; Thu, 8 Sep 2016 07:03:27 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BN1BFFO11FD047.mail.protection.outlook.com (10.58.145.2) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.587.6 via Frontend Transport; Thu, 8 Sep 2016 07:03:26 +0000 Received: from [10.232.14.87] ([10.232.14.87]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id u8873Mds030545; Thu, 8 Sep 2016 00:03:23 -0700 To: Ferruh Yigit , References: <1466510566-9240-1-git-send-email-shreyansh.jain@nxp.com> <1472219823-29486-1-git-send-email-shreyansh.jain@nxp.com> <57C589DB.6010704@intel.com> <9fc7b95e-d0fd-b82d-2643-239f209e3aaf@nxp.com> CC: , , , From: Shreyansh Jain Message-ID: Date: Thu, 8 Sep 2016 12:33:38 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9fc7b95e-d0fd-b82d-2643-239f209e3aaf@nxp.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131177918069467301; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(1109001)(1110001)(339900001)(3190300001)(24454002)(377454003)(199003)(76104003)(189002)(31696002)(64126003)(86362001)(8676002)(31686004)(2950100001)(92566002)(77096005)(87936001)(104016004)(81156014)(5890100001)(356003)(7846002)(626004)(50466002)(81166006)(83506001)(5660300001)(8666005)(85426001)(65956001)(586003)(106466001)(50986999)(54356999)(76176999)(68736007)(4326007)(65806001)(2906002)(8936002)(105606002)(230700001)(11100500001)(305945005)(47776003)(97736004)(189998001)(36756003)(23746002)(33646002)(93886004)(5001770100001)(65826007)(4001350100001)(7059030)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR03MB2447; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD047; 1:Oz3LADskw/MEysEokOXTXcvHGizTmms8ATttZD12kXysHTQ7Ye/U/wf21itASkRtNDcohnFEChElGYmLHshzYQms2vxZTWfiMpDE0klTfO6mbwIT7XWUw8mzrbTXkRcB6ded3TEgckBKssR+8EpFTmRLvKvuT2DyJGLCjpsn+TXn+nndcv7+Ev53zd1k3C09K7Gm3Z36WuqjfFJIW1OVJT4KqreKnQJi/NsMHrTMjCtFqF7Fdza+uGeyOR2qQPfa7H/y7IYFgwVTBwtEzB/kIQcXSopNVAxvnR02tZpZ46Z5qBh7hNXDaWNXFICJ0Wp8Bj96TUnB7eBkZTFTMy8E+euUjlXaUZ0hoXtLHPOIyiwwuZd/2AIkrFixa1vmvmCw9KRi8tJ4FWqJtYzMZSxlxEyG6Ys6m3JTg+8zfKGcUF8bvxKVtvV85qOdldc/Dig9x/CPJrsCTMZfMbJf9twY8NakDU5f1uH78u0h5OLisL2dKSYiKuZEDqUtqvX19kPtOH0JuKDwqbA6PlF1WSvr3tbktlhXA7GsNeL1URZpALLWCViXG1n5AbPgSiilbaXQ62XLrI6lYFa0JenIJGCMyyip04h7vSMsPNIKuuVxoZeKAtteakDLctJd02I+0I0T1Fsgi5oJYi72//mzlKIZsQ== X-MS-Office365-Filtering-Correlation-Id: b7cc49bc-5842-438f-25e9-08d3d7b63b5a X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB2447; 2:8jCBvMFolLxX8yjks8nFHtJ7U4641IeyLwguDI5r1buH9K6z04kM1OKNnH5H7H8cEF7fwlZtpz+P/bgYHSRSOTGKWyiVnS5aHog7etS7I1NVwMWLYFb47vFkc6DEHYKqkQi/0UQrHEQqRxGcbiwSXwTidhxUuvmf+W3GV42xNAFejuvcckB0yFzXTDciwOJD; 3:VuMy5VWjM5QvaKTG4kzAd4dpk6WFq31S0WDP1KzeKbwA5EBCku0oAYWWGfF4pNUI8V/D+eyDVfjM189RcEiupJsH1NkDJ6BIAzFNkhUKxJqDtZkAhNV3BY8UpBWdESNSehejKNWWCdyDggEpqs3Q59TlP5bhOAjqa9jdbomeJYWBSzmjp9goNGrq/P4BNiT1vCqXN5l/kOtmhgeK7fta7sZUcznpPY01g49xInikx+M=; 25:XKs22Pb3AXw9weUaPqq0tokYPDxXHfHtnbraRUSsECQPd4Ap7Voqkcs0KCBUIuNuhsZENL1uREk0GYKsvFqV0D5E5TO49Lo7GUDz/G5dyCP6zrfKinuPtdqNXx3XS9k+PRPj0/s3VIWya38hNIB/NadrG7vAkRKVWhkBE4YjSd9TrLB2Gb6GbByvYu7CgV5r1ZcTxQrUuTD1t6c1v5AtipkvO/jxYPYHz8vdis3EEVZ0nSltsLYpCDfPXI50+awVueCmWI5T3cqt4zi9D+gxyXKwnb9oR97ySJjDn4jJFFUgWlGUV/aeE36UoaAJtx6/H0di65YyhjppZPV8gvacS7u3scGI3PVYCopJx++uTFNrMz3d8MeSmwtY5PkUoTn0xwprdXVAsVCdpKjVT5bL6WlCcs91OBdtPekdtxXYeV8= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2447; X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB2447; 31:GJSrPg+9ueE13ehksWs+3dwspakDSWUIZLQbk8hPUFsBzgD4Uc5uVQm58RAJHB56p9YIqDyM3Y7hMEaA4z0gXnN5nR0nEJlAjpaL66Ho9fDxyedzFPZh//UauC3+4rcVBo7vj2psyqSa1iWPl5GX6BNicQMjvA3aRVRMbxlgLlW3tSvwn/p+Fr8Npk0AfItv7/5873ofIPrmVr1NnjdLwSbu/oIIas6UPOozxOlHOFQ=; 4:VtfjWcfqIVMkTpmD13Qyv9PPCWUVm1luV3eNQOtbe/WanN3i50ePVbK5ggYHBPIeIJ8I7LvhGcPw3S/r5q7xseKKl7hLPTYHNkZp/OrB659FRzdYaCx6qNljrJ/kpAtYFCLQSHZC3o/mbJq6IK6FjJXjB4fmurREXiqOrvNguXA0zG0W5JZsAyt0QJM3q/3FoO4MjFcF63ZjWYF6zDXXiN+eOcK1fxykIvc7ltdz7/uu8HWo/YOX1lqRCLMLApVxNxXl2+8F6+rOYK7JzPH3pji0eIlgFNYo2nZjLM6de+zAkQetL1JVsPlG7ySTqO8K2Ekh6CrxFKf/JpJapMjJanMSkW7ALcP2pbO+xR0Q+l93LEDEYZUBM4EjLDGAHrlUZtnDVZp/uKybqlO29GGKd5nKKr7Joisg6fh4TUdxR6fhmXkrCeT68pfE/8yRVKajcKSgdncc66KfSfiKe6S47ffZou3xBU1QCKPdy5CMQcz9IBPo5YccOYOogNindz15 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13017025)(13015025)(13024025)(13023025)(13018025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:MWHPR03MB2447; BCL:0; PCL:0; RULEID:(400006); SRVR:MWHPR03MB2447; X-Forefront-PRVS: 00594E8DBA X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; MWHPR03MB2447; 23:T5qh4Rjgch45vOfx9IB+/SCByyKz8MsJFx/0V?= =?Windows-1252?Q?URgChBpJNfrfVINO7CnEaA5fn18/1pbgBWlZuUbuQDzAKpeOseFVDbqK?= =?Windows-1252?Q?bmOiZ+ETP3whiAr5Y0vbz1UfCr76NyNMv2cUuxIZhg4l4RZPo5eRpa6e?= =?Windows-1252?Q?yznIguS82vuMcsDfYmZTI9gCzDDfQZjGwDYOMYkB/yFXRrF/cTNJjXVi?= =?Windows-1252?Q?ZR/GBmPEmIqpJAm/riVp7fa3P8rWGAcGfasUPCAfDAZx/ff+KYhmEONj?= =?Windows-1252?Q?1FAmluJN2fcOmcPsvfKXXuAr2O0DEcG9Fjmf4gc9YFf8KUvryhlhJKUe?= =?Windows-1252?Q?ngNLadrlzZHnxqt8Yc+OR9ZISlAEDg4hSTRA/nrt5NwwMc35RUHNs/A7?= =?Windows-1252?Q?BK5dU8gPtqF8D1QzC4aYQV47yAbopy84/Lrd/g/mm8flUIByDsuvcZhX?= =?Windows-1252?Q?jDZGTMeyDOozOyGIom/GL5WgIcX1Kiz2W6yqJXHUyTs3beNTc2nlAHbt?= =?Windows-1252?Q?zVHB0Bvdr44e7dKugae5TzHDOAjN+gsAPWmHchITZK+TYb3ASrF0F2PY?= =?Windows-1252?Q?UhQQ6detrJCbzBecqkCD9KQYJvayrehTIrkdTZ3tFMOc3IEdFiXtyG1M?= =?Windows-1252?Q?Z8gcfRCZhQ1Kr6VRokxR/1QzhKAi6St/U3QcOnq2zggFPTrItssWUixe?= =?Windows-1252?Q?mynyPsufTRQjoHcKLF4su2iYXPd+kmPuUsVj3tH4JcNNuOCRYqSKhGXO?= =?Windows-1252?Q?UpQU4N/R6TnFBMwKjMAzcC4/0GcPZwR7iDhhP8PNMTbmtI+0iMyA6pHe?= =?Windows-1252?Q?D9rMZu5+90ykdW96DH9iEr4MyHD1RkroIFG9O2/uGf/CU478YhMkL4L3?= =?Windows-1252?Q?xBfe7xDiWknhmmx6gYqGX3HmrPVSlOMdcXfNB2i7V4mcRMaUBwhKKbrI?= =?Windows-1252?Q?US/qK+rKG+pAP9ozggCUl455SnzvX5O57Q2vZmi31BgvyXw/8ukki37M?= =?Windows-1252?Q?OssXEAhssVh2Mkh8mGJBdV4tquRlKLxghkhYRa1kyhILWIVQUMzNJolJ?= =?Windows-1252?Q?NFyhKu6ypSb9dkr04aPDBTa4xJKaVeOaFcSL7TNasIsfa2XFFx0cwa9A?= =?Windows-1252?Q?/DKtbIBp4WEbm44zYnDsh+HtTnAvG/hDictYsJxGH6ga/L9aBQY7QZNf?= =?Windows-1252?Q?ZQt146PminuOsf0hfiJ1jST1Lf+k0vDK5/eAmRHkil90OhHF+aXauR/N?= =?Windows-1252?Q?8FLnB4scQljk19mXyVqV8Es0vRmuVlwWn24DilUKlLqmm+kZ+gC1x6Uq?= =?Windows-1252?Q?r0Py7HjHh8ehMphYCxZkW8i8bvfh6ATqjw3eDgp6pNFLhOEKP6BDCglt?= =?Windows-1252?Q?oNW7xnOuIQLBCkPpHsnIXE7Og+xBoM3USOdoyA1arPTHSTvMEDFWp/UG?= =?Windows-1252?Q?XnbJuM03o+BZnU8wKdoJULTul6x9MRzLfmT2uHMout9GT1WOxD0Ndvvj?= =?Windows-1252?Q?Vp6k1EMIdYd98GjBrnCl7eTUu9atHAXDuZzC1AxQURx38rFiA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB2447; 6:wcgoea37Z9Q0t1233Wk2Nv7UnLqn7N8pP3Llipcfrgpe6XPULt2CJcp4pUn5e3QHSRhQr07NPVwQH6r6UnE6R83QmzsZvI4ZEzLuAjWaAONsGVeQG2IilJMiVZJQzZHVxWklw+6qvKvLfoJZ4PH/Icux/y55xNFdGSwXHdsiLHiRHqTIyIw/1ENKHYMlo4HabEuQJLK07yRAUVy5ETrk10VqoMCOuE6M4R8Y6HFBi7cjfhi5OGfiia2ZfS2+3/c7rj4+Ev/USRp7ecU0nO4HlmtkJMYYyfFvA8G5m7yPidU=; 5:njwvDlo4XqNsJfc8zZGILu2v/KwxllWu3GM09uM4YDXKmtnGdSiyTf+4rAyVH48ERtLGDOrpAghZcjf0f/WMJ/r20bjztPf6seVtbseHPLXzbY6HuQK0iuZPIG/0G641PkeQ0HsOv5l4aldQ6i1ECl9EaxRMokCZmaWAB5FTtg0=; 24:gtJYsEENP0Yy4QTZznIbrHO+GwkUM0xSakR1WyhNO3SJCmpi7d2TrP6RgEFzFwnlmWcxEoGej+rhCp9g9VIGHiQYqDH6GdkBhjwrIsR9iHs=; 7:SfRgDa1zgS52Xle12WUaGN46Vp6RFAm3PYpn3iEH7zrmkZITbwdfF6IpsYtruWtIfvnvFsZ/h1cPoQmChMQEplHzaZMGUOW/euX22UG8a7Yn0/rB29Nu2Ri3Qcj/ktNBzbeOFTaV5txU8zG2U9RI+tlP8KnBd6aqToh5qUEha9FLoDwvv+QfHAW5uPpi9wG3GVri+QRRqcnYFkBxsC8E/cr7jytTTWkn2NAIEYPvlkBwKNp2Zux/iWREo1yX61u7 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2016 07:03:26.7283 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2447 Subject: Re: [dpdk-dev] [PATCH v8 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: Thu, 08 Sep 2016 07:03:30 -0000 Hi Ferruh, On Thursday 01 September 2016 06:06 PM, Shreyansh Jain wrote: > Hi Ferruh, > > Sorry for the delay in my reply. > Please find some comments inline. > > On Tuesday 30 August 2016 06:57 PM, Ferruh Yigit wrote: >> On 8/26/2016 2:56 PM, Shreyansh Jain wrote: >>> Based on master (e22856313fff2) >>> >>> Background: >>> =========== >>> >>> It includes two different patch-sets floated on ML earlier: >>> * Original patch series is from David Marchand [1], [2]. >>> `- This focused mainly on PCI (PDEV) part >>> `- v7 of this was posted by me [8] in August/2016 >>> * Patch series [4] from Jan Viktorin >>> `- This focused on VDEV and rte_device integration >>> >>> Introduction: >>> ============= >>> >>> This patch series introduces a generic device model, moving away from >>> PCI >>> centric code layout. Key change is to introduce rte_driver/rte_device >>> structures at the top level which are inherited by >>> rte_XXX_driver/rte_XXX_device - where XXX belongs to {pci, vdev, soc (in >>> future),...}. >>> >>> Key motivation for this series is to move away from PCI centric >>> design of >>> EAL to a more hierarchical device model - pivoted around a generic >>> driver >>> and device. Each specific driver and device can inherit the common >>> properties of the generic set and build upon it through driver/device >>> specific functions. >>> >>> Earlier, the EAL device initialization model was: >>> (Refer: [3]) >>> >>> -- >>> Constructor: >>> |- PMD_DRIVER_REGISTER(rte_driver) >>> `- insert into dev_driver_list, rte_driver object >>> >>> rte_eal_init(): >>> |- rte_eal_pci_init() >>> | `- scan and fill pci_device_list from sysfs >>> | >>> |- rte_eal_dev_init() >>> | `- For each rte_driver in dev_driver_list >>> | `- call the rte_driver->init() function >>> | |- PMDs designed to call rte_eth_driver_register(eth_driver) >>> | |- eth_driver have rte_pci_driver embedded in them >>> | `- rte_eth_driver_register installs the >>> | rte_pci_driver->devinit/devuninit callbacks. >>> | >>> |- rte_eal_pci_probe() >>> | |- For each device detected, dev_driver_list is parsed and >>> matching is >>> | | done. >>> | |- For each matching device, the rte_pci_driver->devinit() is >>> called. >>> | |- Default map is to rte_eth_dev_init() which in turn creates a >>> | | new ethernet device (eth_dev) >>> | | `- eth_drv->eth_dev_init() is called which is implemented by >>> `--| individual PMD drivers. >>> >>> -- >>> >>> The structure of driver looks something like: >>> >>> +------------+ ._____. >>> | rte_driver <-----| PMD |___ >>> | .init | `-----` \ >>> +----.-------+ | \ >>> `-. | What PMD actually is >>> \ | | >>> +----------v----+ | >>> | eth_driver | | >>> | .eth_dev_init | | >>> +----.----------+ | >>> `-. | >>> \ | >>> +------------v---+ >>> | rte_pci_driver | >>> | .pci_devinit | >>> +----------------+ >>> >>> and all devices are part of a following linked lists: >>> - dev_driver_list for all rte_drivers >>> - pci_device_list for all devices, whether PCI or VDEV >>> >>> >>> From the above: >>> * a PMD initializes a rte_driver, eth_driver even though actually it >>> is a >>> pci_driver >>> * initialization routines are passed from >>> rte_driver->pci_driver->eth_driver >>> even though they should ideally be rte_eal_init()->rte_pci_driver() >>> * For a single driver/device type model, this is not necessarily a >>> functional issue - but more of a design language. >>> * But, when number of driver/device type increase, this would create >>> problem >>> in how driver<=>device links are represented. >>> >>> Proposed Architecture: >>> ====================== >>> >>> A nice representation has already been created by David in [3]. >>> Copying that >>> here: >>> >>> +------------------+ +-------------------------------+ >>> | | | | >>> | rte_pci_device | | rte_pci_driver | >>> | | | | >>> +-------------+ | +--------------+ | | +---------------------------+ | >>> | | | | | | | | | | >>> | rte_eth_dev +---> rte_device +-----> rte_driver | | >>> | | | | char name[] | | | | char name[] | | >>> +-------------+ | | | | | | int init(rte_device *) | | >>> | +--------------+ | | | int uninit(rte_device *) | | >>> | | | | | | >>> +------------------+ | +---------------------------+ | >>> | | >>> +-------------------------------+ >>> >>> - for ethdev on top of vdev devices >>> >>> +------------------+ +-------------------------------+ >>> | | | | >>> | drv specific | | rte_vdev_driver | >>> | | | | >>> +-------------+ | +--------------+ | | +---------------------------+ | >>> | | | | | | | | | | >>> | rte_eth_dev +---> rte_device +-----> rte_driver | | >>> | | | | char name[] | | | | char name[] | | >>> +-------------+ | | | | | | int init(rte_device *) | | >>> | +--------------+ | | | int uninit(rte_device *) | | >>> | | | | | | >>> +------------------+ | +---------------------------+ | >>> | | >>> | int priv_size | >>> | | >>> +-------------------------------+ > > I am in agreement to all the points you have raised below. > Still, there are some comments: > >> >> There are also "eth_driver" and "rte_cryptodev_driver", which can be >> represent as: >> +-----------------------------------+ >> | | >> | eth_driver / rte_cryptodev_driver | >> | | >> | +-------------------------------+ | >> | | | | >> | | rte_pci_driver | | >> | | | | >> | | +---------------------------+ | | >> | | | | | | >> | | | rte_driver | | | >> | | | char name[] | | | >> | | | int init(rte_device *) | | | >> | | | int uninit(rte_device *) | | | >> | | | | | | >> | | +---------------------------+ | | >> | | | | >> | +-------------------------------+ | >> | | >> +-----------------------------------+ >> >> Is eth_driver really needs to be inherited from rte_pci_driver? >> It is possible to have ethernet driver, without PCI bus, at least we >> have virtual driver samples. > > I agree with this. There would be cases where even non-PCI devices are > ethernet devices. As of now, in the proposed patchset, rte_soc_driver > has been added into this but it is not a scalable solution. We cannot go > on and add all type of devices into this. > > Having said this, back reference to type of ethernet device would be > important if the ethernet driver needs to refer to some hardware > specific information as part of rte_xxx_driver. > >> >> How about: >> +-------------------------------+ >> | | >> | rte_pci_driver / | >> | rte_vdev_driver | >> | +---------------------------+ | +-------------------+ >> | | | | | eth_driver | >> | | rte_driver |<---------- driver | >> | | char name[] | | | eth_dev_init | >> | | int init(rte_device *) | | | eth_dev_uninit | >> | | int uninit(rte_device *) | | | | >> | | | | | | >> | +---------------------------+ | | | >> | functional_driver ------------------>| | >> +-------------------------------+ +-------------------+ > > Even while I was re-creating this patchset I was wondering how to > realign the eth_driver<=>rte_eth_dev (even naming is inconsistent) with > rte_*_driver/device and rte_driver/device. > I agree with you that we should link eth_driver->rte_driver. > > My only concern being a case where a PCI (or other) based ethernet > device needs access to driver structure for some info. Is that even a > possible usecase? > >> >> Currently there is no way to reference rte_vdev_driver from eth_driver, >> since it only has pci_drv field. > > True. > >> >> With this update, it can be possible to create eth_driver and >> rte_eth_vdev_probe() for virtual drivers for example. (Although this may >> not necessary right now, this gives ability to do.) >> > > Agree with you. This change can help various other similar cases. > >> >> >> Another think, what do you think moving "dev_private_size" from >> eth_driver and rte_cryptodev_driver to rte_driver, since this looks like >> generic need for drivers. > > I don't see any problem in this as well. > >> >> >> >> And last think, what do you think renaming eth_driver to rte_eth_driver >> to be consistent? > > Yes, I think it should have been a most basic patch - > eth_driver<->rte_eth_dev combination has existed too long. > >> >> >> Thanks, >> ferruh >> >> > > - > Shreyansh > In the v9 that I have posted, above changes have not been incorporated yet. All the above changes are dependent on one change: to introduce rte_driver<->eth_driver relationship: --------------------+ eth_driver (PMD) |-------------> rte_driver crypto_driver (PMD) | ^ | | --------------------+ | / +-----------------------/+ | rte_pci_driver | | rte_vdev_driver | | rte_soc_driver | | rte_xxx_driver | If I go ahead with above model, PMDs would now have to define rte_driver, rte_pci_driver and eth_driver. As of now, PMDs only define a eth_driver and embed pci_driver into it. This change makes the current patch quite large - which is one of the primary reasons I postponed it for another patchset/phase. Further, now that eth_driver no longer embeds rte_pci_driver, it becomes unused in the PMDs - it was only being used to access the init fns. I am still to find a way around this - whether to completely do away with it or have some macro attach it to another list. I will work on this and post another RFC style series based on current rte_driver/device so as to take more inputs. - Shreyansh