From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0078.outbound.protection.outlook.com [104.47.34.78]) by dpdk.org (Postfix) with ESMTP id EC206691A for ; Tue, 13 Sep 2016 13:15:20 +0200 (CEST) Received: from BN6PR03CA0070.namprd03.prod.outlook.com (10.173.137.32) by BY2PR0301MB0711.namprd03.prod.outlook.com (10.160.63.153) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Tue, 13 Sep 2016 11:15:19 +0000 Received: from BY2FFO11OLC003.protection.gbl (2a01:111:f400:7c0c::195) by BN6PR03CA0070.outlook.office365.com (2603:10b6:404:4c::32) 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; Tue, 13 Sep 2016 11:15:17 +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 BY2FFO11OLC003.mail.protection.outlook.com (10.1.15.183) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.619.6 via Frontend Transport; Tue, 13 Sep 2016 11:15:17 +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 u8DBFEGA032484; Tue, 13 Sep 2016 04:15:15 -0700 To: Declan Doherty References: <1466510566-9240-1-git-send-email-shreyansh.jain@nxp.com> <1473257297-7221-1-git-send-email-shreyansh.jain@nxp.com> CC: , "hemant.agrawal@nxp.com" From: Shreyansh Jain Message-ID: <764a318d-1293-9c97-52f6-64fa13824be8@nxp.com> Date: Tue, 13 Sep 2016 16:45:44 +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: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131182389178064697; (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)(1110001)(1109001)(3190300001)(339900001)(199003)(189002)(377454003)(76104003)(51444003)(24454002)(23746002)(4001350100001)(77096005)(36756003)(87936001)(356003)(105606002)(4326007)(15975445007)(586003)(189998001)(11100500001)(76176999)(1720100001)(54356999)(8666005)(230700001)(5890100001)(626004)(50986999)(106466001)(92566002)(50466002)(97736004)(110136003)(31696002)(86362001)(561944003)(2906002)(85426001)(2950100001)(83506001)(68736007)(19580395003)(15395725005)(65956001)(65806001)(8676002)(81156014)(81166006)(305945005)(8936002)(5660300001)(31430400001)(104016004)(7846002)(33646002)(47776003)(64126003)(65826007)(31686004)(15519875005)(7059030)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0301MB0711; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC003; 1:0VNAEULgZlIEIDGKg7Gjtgf3lr1Yv8ol5STQaQaMfCkTPss871QjF44nspIOQoULConri5zKifLhMr8IpczJ9lhiYmxwvHjaKI923h3wqw0n7fOb/4xlqEKy3IjEst8ZNACNawKp0ShuxMgadXKmFY1C8MDuZVRb5fm1YxcPqpAI4tYBUNDk5mdlXQ4TKgJuv0L5u0URJMoD1MOCW5J26n/+yEp9p7tRFAEOy1KvKcoLX5vA1sxQst87Na4RP/V//am0g+UKfGGeiI5DC+1/Qq8TPR390FS4IC7jQ71tXWBEdutgKdK389iPd9CChHFl3pCfBSqjBIBbV2OFlq2/tZr1WXmCHAxtiXqOk4nOsM2934FXa6T68lhC8neGdzIxeiPlzCXeQ3narmbcoUAo1NbK9CMAfPXPIKqkCUBnJfsqzXbcdq0igYShuxBCXDFU0z+NbhohmS88P50OSOh4GJbCVmtcoiROLvrzZfz0Qq3WrOiy4K1N5ysJGSbYClkf4iJPGSbnHnXMaV86lIAcNiwm4gcPcbwmZqOkCprw6zaU9eK/0BA9dfigLRqgiuL8M4DrmGPqr9M930pgexrQBnUMH5KrOeW3U8giPq9Tu/jXT4dbE3JcX/SwqZfu9GjPIMnbuedajlQIDGm+vJZCVQ== X-MS-Office365-Filtering-Correlation-Id: a4faa875-fc46-447b-7ddd-08d3dbc73e33 X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0711; 2:Lq5FjDydLNvCiWWwek3Wda38HvxChZfIxdl6h63/kCEx/iuPypw5kyXdq7fedcOE6cPNzE4C03xuiClzFM/pB5IOWiqO040oJ1a7IxUIq6DFPN+R25IxnJWmbuPT+tHL7J8NfGI5iG2XJA9tIezWDctCNQ09TfvlXG1i33i3NuamIneZlfu+Ixq1zi/s74Zk; 3:OKdwPMA7aMSABiGt3aZ0D2V7GrkpPY8BZs53tcjzJQGLbUf11ldeNNRzACej8sWXxsnJE8J6czJQtjif3dOHjI/ZjqEWW5M5DC4qc4k23eEA8/NIF7UqLnlJXdog6MmEqdjTF/98+SA1vFfJ29YxLNQMDVnzPvIKwbCUYNXCREXpr79FsAIitsmVKtwhChAS7pEeCVYY+jfkoJIO96DT88b+oA/bLpyydR4PX9scSBs=; 25:5oAidVyeTuPsvwunr+MuKfuxddruatcPlCOyxyNETK/HrSV6qzZXQwpc1UoFvPDRJD+w+Ya3HSk0k6r+LLHdtOh84Gde4pIcZUUP0eiHOxVOzMO47puyszHicitMHtfPQsE8y6KjaBGkwYtf+anOy4FZOQhdz6Fo9VMhEmOn8XImQTpQ4LGLTyO7kio89YVSuSJ5EberNDlfphxGxSXautY5vc8vsbVAIgVi/DGEJYtSofiRJw7ygu7OBvKRaND1aboFGoKxFsty4GZ8YngTzjvaghWy6+7uHGD2fBqW/s9iBQXYIbSOf2RJk4VSb/Dovaioq4e/YY5TfHkVFNKQ1GM1wJ4jt9WlRXBt8Ulhq/Oi/sbPMlw0luMtuGgMZnS85XgtlYoPwgEi7sD+LlA01t6hkOw1uZoX9CVORhnvYNM= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0711; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0711; 31:RB25gp6jZfkQz+/yZr4OZIFWS9eetVN1vPcVROgntgj4WqOu1pWd30gRcrikXTOoqC9VY/Qh03dZ4g12BDO1V+0ijdMsmd4VgDPLBEwntm28wk5s2PCvsomey2LOMs40HQs7Imvlo80dGFg9LlckvhSOuS2ZCRauHb1WOKSEq4W2s9/Q3E5wVwZADQonR6xee3MY6bsAzrG4RoFiAoa5W6Khj//DJ4BzU3U6/F2y07Y=; 4:MfvfuTd5XnWtD1apxhIjlF8hYwHuLOSJ7WIkibmkW6oa+K1drnO3iQzLQ6LOYSmPQ9JaHYM8erLbqG/MB7n301dkZUOhKfWwD/U1zINGDeFA+3AHU/ZF9h5aQNsoepttL5Ele+QDoceg2cLLEtvXvAViqUG9J/30aGcgZR1WuhuNJbBK3Bn/Q4gZmlqfFKp3ANJlEUxfZV2EPNV6PwctWUz9O7ViPEDX/1DBjHdbdeCCE3lUkCUUFtNL9uhwPFiyztjmJqKbVd+0XNV8VeleVd3p8HlpK3nR1TmXrFyBZx5tddwV9WbohIhmFCMo+Y6tKz0YKnwCbjcgeXKjuojB5b9qrKnPEqoJ8GTk7nsKWfa6fhzKBP+5hlOrGKtYDrm3+aTCa95PS/+UUOKzHp9NV2CUqZrcYrP6Hn4pKHVZD4NWvBo3lAkGABS9w5n/fB3+jxelYkQfLtFAUQ14a6o+vlpi26A6IRxB+0Epbqj2vw/xSZN3uDM4M83TvMknAPthKi/sj2DySbKBBXY+xaDkpxCyU1r7811H7uvDCf3hVn0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(247508381695603); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13017025)(13015025)(13023025)(13024025)(13018025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BY2PR0301MB0711; BCL:0; PCL:0; RULEID:(400006); SRVR:BY2PR0301MB0711; X-Forefront-PRVS: 0064B3273C X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR0301MB0711; 23:93PMRxTVh0r2wzgQJ0Ov2LBfgSOfzbqjaN9?= =?Windows-1252?Q?dDxngmIJ1qJo+joDviqz2BkGaVxKbSbjbqrWAbktPdY0Mv+LBugGWwUK?= =?Windows-1252?Q?iKekLjjmUCwosWChYr75efWsGUV5MEtSlY+TyW7Lzbcpe1Yo7CqDUXyT?= =?Windows-1252?Q?rK+6KmKJ9aKzxavobYvK3Kd8kH0hLbcK8Qj4/cZXTxYyt7s+5BAPJ/Lf?= =?Windows-1252?Q?+X55ZQ67QfuvwE4X+L3fLaUkdbeoZg4s0WeSmPlV9m2v8YWYfuCmxR9g?= =?Windows-1252?Q?yHlBB8O9zHfEZbprEdNY2jLz2CVFuHJqjR1fxe/NUCOoF3aXSpJfmfRb?= =?Windows-1252?Q?xJynB1iwMjOgbN0bMgyHvh7iTUwdI91/YWSRG5HWvfzgavZWD9IKwu17?= =?Windows-1252?Q?1HI3mKoUcCrTNSMTJBhldUnhLyyl0YPIi1ARkqSK772e7W8NKINSPWZe?= =?Windows-1252?Q?Dwpa6ujhdbG8JOzBWQgIscRa4z6h4N8jImrc/uxmU6BtKsMuOKmXBdED?= =?Windows-1252?Q?E4w1v8bv5iCx88HKzjTWFYLVKM4+Axa480bDteW36K5ChH09dRRJCyJu?= =?Windows-1252?Q?2Y6pTl8eNe+CfmIVO5pmHyesJUvoqVBfzsnkiW2cM9UCUq40qKeIstW8?= =?Windows-1252?Q?P3d/YSx82+F2luylVFgH9JI7jY6FLe1/iQIvePIHcpZWyrmWj1nn2/CU?= =?Windows-1252?Q?tWmXKOTLzzkEnov/SLk9QljXuFjaCtv88/M4c7fIatjbeEKX2N1YVP3p?= =?Windows-1252?Q?dG9UcZ1hizUtl9hSL1qqBl8pFmYAkDUmFdLXgkcSF/6grIPs4Gg8s0RE?= =?Windows-1252?Q?7eODUVilreZK+j7q9ffLYQfG2dWYlBK/tZqsPnhn7J/jOPVdlDcDgL/P?= =?Windows-1252?Q?Q+Z7Ojb6MDhZ+0ohLiP0NRrbgWEzrIYqOsF9/zuvl+wYOPkLNTmoKx3g?= =?Windows-1252?Q?9bvlZ/PidgdHDjobBkiNPg8zJMJ70lyQ5K8fCbn0HlrKTKgWpLeXOS5m?= =?Windows-1252?Q?K0xwJYH6VpVo0Sq4jhTGMFTqy9vNMm8nXJ2zz5207oxWZtzml3W1CRpW?= =?Windows-1252?Q?22NTbAhJPcht5gfiAaup5TUBfehXbgUmjV47zJ2sEKb0aFcdBjsZL/nv?= =?Windows-1252?Q?Uxye8OzJhgun2fA4fMuFLC1xgl+n9KWDgeW4BAkQ0WPP+UEvMKpE1+to?= =?Windows-1252?Q?3g2u/bGwKssjC7Z01/ApcXdEabkHke7iU/A2qmAtqxXnV9nOTSk12LKO?= =?Windows-1252?Q?P3a3E1mUoy1yEojWXUqiZ5VEbVaTs9/MNjyUOitJlR933vDGSb3LkO6l?= =?Windows-1252?Q?UvMFZBfX/OGOdxAKqUyDk4sN0TcPvxZ3WizTxCbler4jT1gQIK1MsCqT?= =?Windows-1252?Q?Wg00oIQz+QjmlnvbcvUTz0bMzJCDF1WA+NcgTzfeYBuQGpfVVNZpshKP?= =?Windows-1252?Q?J85JQb/gRSast421dJSTM1JDbXVYH4/BS+2Odd8OFCw18He7FUWfd8o0?= =?Windows-1252?Q?eDANFfgY2jmsNNCMX9EMebR5LapWc5ElWADrXmKYYGakSYSjTc0QOZO2?= =?Windows-1252?Q?QXT3f01VyqUcV+r62Wlwa20jwm9LOST6uko85gPle6mAi0qAxJMYYYcC?= =?Windows-1252?Q?jJRenKezwMt2ZRHRb0f9qxdcea3HrJ6oBH1pXXG3j7RBlicDIwLPgYOm?= =?Windows-1252?Q?tfo/eUm3Ckpddku9xrTSvQ0trhlOj3kqloje5f6sJOQTlbv5v+Kjd?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0711; 6:aT6NKEjpc09FAchTNxZdtk8lFoV/HbfZNHoUbdGIa8PAii8NfanHIAtvhCdwF3uaLtvWWj9BbPnjRbez0Ruc08GPOWvmewtdZvFLNCZun6gphsmDOsP4xXhIuDtiXwMXdnS0DM5TrYClSJJNhFeGo+YhTloXESGZh+/P9vNEM/OQgGW00TsHnq2gVCl8b/351LuxcpUoMiPl9cGy6yZA6dmmVOXOcVgtMbvii93j4HB/mjnousy6LIe9glHxak06KoWw/xrO8/1PlBbp7eS1KkWlr9BM9+ftbeFdBlVkF+A=; 5:4LUV4PZikZ791Yfgt1x1q6TKt02lYvDHRRlv75TeD9tqpJUCUoYvZLTwLDz7JNWgPJC6riG6j6PBwx3Cy2JoizzYLGPv0KBAJSHs/aLNv6QiInLi59rqfYNYvZJx4NRQGZBqs9105Ga5/NTPxCnzsyZOugn7FJ4kl0mrALfv2z0=; 24:GRg8eOaIgggVPKaw/nxL9eBpLdfRH7OsNIFwHRKNxG/eC7vbq4U70EBMUBy4W/LZYLLkxiI5WuG/DPULMMw3OVZSHQ5XWN1ml8nhwkqWuK0=; 7:RvOvgTyLd9CSaDJySM3erwRM58e1AM3StJ74usC/6M4sc4hnI/eajT1YwpEvVpZNgH5fqE0CUfzK/2TBYWkH0M0TVUO5bhwWBZmEz7ivl2s7ZgdH5nudTQ9RbNUeyzrjRGrMI8jf2GVdceMj1E5pFiVJM84wqKYfjErZTWgRrBE+g4TZ5J03LPW8slBz4qsZKtP2zP25OErWNF64yMhz/X16pJXjSGxvmRVm9NT1g5KOrtGlQ8f8NgvMru9jJWI7 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2016 11:15:17.6036 (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: BY2PR0301MB0711 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: Tue, 13 Sep 2016 11:15:21 -0000 Hi Declan, Apologies for delayed reply and thank you so much for your inputs. On Friday 09 September 2016 09:41 PM, Declan Doherty wrote: > On 07/09/16 15:07, Shreyansh Jain wrote: >> Based on master (e22856313) >> >> 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 | >> | | >> +-------------------------------+ >> >> Representing from above, it would be: >> >> +--------------+ >> | rte_driver | >> | name | >> | | >> +------^-------+ pci_driver_list >> | / vdev_driver_list >> `---. <> / / >> |\____________/_______ / >> | / \ / >> +-----------/-----+ +--------/---------+ >> | rte_pci_driver | | rte_vdev_driver | >> | pci_devinit() | | vdev_devinit() | >> | pci_devuninit()| | vdev_devuninit()| >> | | | | >> +-----------------+ +------------------+ >> >> >> +--------------+ >> | rte_device | >> | name | >> | | >> +------^-------+ pci_device_list >> | / xxx_device_list >> `---. <> / / >> |\____________/________ / >> | / \ / >> +-----------/-----+ +--------/---------+ >> | rte_pci_device | | rte_xxx_device | >> | | | | >> | | | | >> | | | | >> +-----------------+ +------------------+ >> >> * Each driver type has its own structure which derives from the generic >> rte_driver structure. >> \- Each driver type maintains its own list, at the same time, >> rte_driver >> list also exists - so that *all* drivers can be looped on, if >> required. >> * Each device, associated with one or more drivers, has its own type >> derived from rte_device >> \- Each device _may_ maintain its own list (for example, in current >> implementation, vdev is not maintaining it). >> >> ==Introducing a new device/driver type implies== >> - creating their own rte_.h file which contains the device/driver >> definitions. >> - defining the DRIVER_REGISTER_XXX helpers >> >> ==Hotplugging Support== >> - devices should be able to support attach/detach operations. >> - Earlier these functions were part of ethdev. They have been moved >> to eal >> to be more generic. >> >> 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). >> >> > > ..... > >> >> 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. >> > > .... > >> > > Hey Shreyansh, > > I got some time over the last couple of days to got through this > patchset and your soc changes, and it's really a great clean up of the > driver and device infrastructure code. Thank you. Honestly speaking, I am more of an intermediate maintainer - most of the work was already done by David/Jan. > > I guess I'm coming to this party a bit late but I have some thoughts on > the the object model that you've outlined it improves things a huge > amount but I wonder does it go far enough. > > I think that currently the coupling of the rte_driver to instances of > rte_pci_driver, rte_vdev_driver etc still really clouds the abstraction. > I think if we introduced a rte_bus and rte_bus_data abstractions with > all rte_drivers having a rte_bus instance then we could further simplify > the driver and device management, I think this would greatly reduce the > number of driver/device APIs in the EAL as I think most bus This is where I beg to differ. rte_driver is actually a representation of a generic bus on which devices (PCI/XXX) would be attached. Creating one more abstraction of rte_bus* would create new boundaries of what each structure does. At least as of now I couldn't think of why the functions you have mentioned below cannot be handled by rte_driver/device - Or, to put it other way, what differentiates an abstracted rte_driver/device with rte_bus*. > functionality could be abstracted into a simpler API. This would also > make it possible to create new driver and device types and allowing them > to be plug-able components into DPDK and which I don't think would work > currently even with the changes included here. > > http://imgur.com/a/3b7XM I saw the image. Key difference I see is that now mapping becomes responsibility of a bus. Other than that, what else do you propose would a 'rte_bus' equivalent do? Any example from current model or PMDs? In fact, already rte_driver itself doesn't have much to do except init/uninit (which too is pending) and some state vars. > > The link above is to a png of a visio which outlines the object model > that I'm thinking of. The main extension from your current patchset > would be that rte_eth_driver and rte_crypto_driver would now always be > inheriting from rte_driver and not rte_soc_driver/rte_pci_driver, etv > but the rte_driver object would have rte_bus instance which could be of > type rte_bus_pci/ rte_bus_virtual/ rte_bus_soc etc. This I think would > allow the EAL to be written in such a way that it only every operates on > the base object types rte_device/rte_driver directly never the > derivative objects, like the rte_vdev_driver, rte_pci_driver. Also I > prefer the abstraction that a driver has a bus rather than it is the > bus. Also I think would be the devices layer to written driver/bus > agnostic, so the eth_dev layer shouldn't know if and underlying PMD is > PCI/memory based or virtual. Only the poll mode driver itself, and the > part of the EAL which manages driver initialization should have > knowledge of the drivers bus type. > > Anyway have a look, and let me know what you think. I agree to your points that EAL should operate on base class rte_driver/device. But, I am still not clear how a bus would add value to this model of rte_device<=>rte_pci_device/rte_driver<=>rte_pci_driver (PCI as example). Can you explain with some example case where this new layer would help us? Overall I feel that we are on same page except the new class for Bus introduced in your proposal. In my opinion at least as of this first draft proposal keeping things simpler might be better. We can always come back and introduce this new abstraction in subsequent versions - it looks incremental to me. And, probably other members on list might have a better view of this abstraction. I am open to discussion. > > Thanks > Declan > -- Shreyansh