From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0070.outbound.protection.outlook.com [104.47.41.70]) by dpdk.org (Postfix) with ESMTP id EB14A29D6 for ; Wed, 23 Nov 2016 10:42:52 +0100 (CET) Received: from BLUPR0301CA0030.namprd03.prod.outlook.com (10.162.113.168) by CY1PR0301MB0745.namprd03.prod.outlook.com (10.160.159.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Wed, 23 Nov 2016 09:42:51 +0000 Received: from BN1BFFO11FD047.protection.gbl (2a01:111:f400:7c10::1:177) by BLUPR0301CA0030.outlook.office365.com (2a01:111:e400:5259::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8 via Frontend Transport; Wed, 23 Nov 2016 09:42:50 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; 6wind.com; dkim=none (message not signed) header.d=none;6wind.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.734.4 via Frontend Transport; Wed, 23 Nov 2016 09:42:50 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:889; Count:13 Received: from [10.232.14.87] ([10.232.14.87]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id uAN9glWm025896; Wed, 23 Nov 2016 02:42:48 -0700 To: David Marchand References: <1479360605-20558-1-git-send-email-shreyansh.jain@nxp.com> CC: "dev@dpdk.org" From: Shreyansh Jain Message-ID: Date: Wed, 23 Nov 2016 15:15:02 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IncomingHeaderCount: 13 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131243677707204280; (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)(339900001)(336004)(199003)(189002)(377454003)(24454002)(85426001)(65826007)(5660300001)(47776003)(86362001)(36756003)(626004)(6916009)(4326007)(65956001)(92566002)(83506001)(229853002)(110136003)(2906002)(8936002)(23676002)(38730400001)(305945005)(65806001)(6666003)(2950100002)(7846002)(8676002)(356003)(31696002)(81166006)(97736004)(106466001)(4001350100001)(50986999)(189998001)(105606002)(68736007)(54356999)(76176999)(104016004)(50466002)(31686004)(230700001)(64126003)(33646002)(77096005)(81156014)(21314002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0301MB0745; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD047; 1:LNQZfv0j3ehdoUbNGEOy5TM5WPb8g0qOze5rwk1Ma8Taya4UA7c7Soi5NzkzKzkiQP8MDVJ+BVY+omW8gf8c/dHEM0dOlUsTAMMwjCtv/IlYBFaNAlr5LOodgfDq/4q9txX2kZYTmUoLh40gtmI7SUWktfij+JjCZiQJjDjfflagYbHRkWcyXCGuhDp1o6HGPA8q5cxPZmpSNtkHid3gJfYUahYMomYAjQ+/r+/ntPam9BHukPKRKahxv/QgrbDuctXXb6FYMmXt7sbszRyOM49imMvmrJ/LjjJ3BAX2ra+XSgQOAqT7RGI359J9s1XV3vC3EARhVdq0tlR8WT1OARJzmtfc7Mt4s1C5wavUfOauyLDMFJa6PIhiuGY8Xh7f8I+CWPe/1KE8Q4uYvvn7y4QqsOCCMHdf9xlEiDjqSoFFtn0FPHI+ZrXfw/CGrvHGgTeavdT3jh/WAlTAkd4U6lN/EVdI/eaY+EMNbcLIeetIjk6iYwMTTRj8Iw0rBR2usaGhXSvxQDhSsnABtJysORRZX8nW01XsdJfJhpGn1c2l+XMIeaRKDs23vvkSaHI+bLyZzUpxcScPpLS8zxVBsr5GYFHUlNW7t0wDIQLNyM4= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0745; 2:BFuLju47Q25FUwlKIDq5neeToS5Ur/CdXDY0F5v/oMHWbjxo3SB0X4vj0igk27S0OzM2G/w6jwXGgU0TXB3Z2OCtA5k8/KAoECVrG5jsYe8qIiKYjORnKZ+ZV8Trl0WhklfeMEh1R92YY9IElRBnJmHMaoLLx6/IlkydKKPt65g=; 3:Pmj3CIPBhSBgPYnayRYQWNpfuEbUTGB/pxOf257TbXCGuucPcXDfcRL2mhZxu/1iq1v9ciUs6cF6bCVvUjxAIh/TvFniatQjURo3JFPu8oxEKujBh3Umrz5igCDEDFMm7l9KDHMK4HNb2KiQeOYZASdSon0jyO9sPgr+uMGrYjsp23sMrcQzuhkQylAoPe7efQlHb/ZWfbs4FIqky4aHUT8W0IougFzLXCVsHK9ZRDONqnMXqKUPlHv5cyJPmhPbMsH1LOG9fEDkDHQLCSjZvA== X-MS-Office365-Filtering-Correlation-Id: 0fa8a2c2-a1ae-4457-955b-08d413851735 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0301MB0745; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0745; 25:+wKYEJiZWXMDRXtsyFT9CtXMeg6GBZY8HX7FYgP3Zjf80xGkj5PdBVEjsKE1/HFAS7dCL3sKBB1orB8SkFBB2MWb3mG8CCXXi3syOyeBJvuuQJ8YPTd6ysxWd8c5qznMfPbbliMmXv13N6bJ7PUz8XoJ3xwsnrdWxevMYkcJOCdcuLQs7q8kIed5jNodnragLog4l1SveKygeHNu/muzX5kBdJ6p0uZt1OsZ7lPMoCscelmwnBsVwT1mGO2oTRsSWHdqD7iujQb6BH7Wx3kjIdgkr/V1zufoq6YG/iwRkX8NDtn0CQ0rczH73drm39/984aGYfEejUInSEwpte/IE6GJt2ENezyBHdYI9nMaxIkhpeALiWRQd66lzBiEcLbkHsvxP9aBXHlT+mVt7Vo+1JC2mBdT1w6tv++UM8KpNtSudX8divqArblM+hEbXLZ3zJKtnosD88wX+AtOjBgcpp2yJmSI0c7yII0PShIInChpg2OZN9FeLgSE/AKEIqNzKiS3NaXFbpNPGJST/m85HkRJFNVMsLZX80TwUQEZN5oE8pDX//15u4n39VIebqkckPH/EILnXdep3xrDPNjz63BICeZ0RSEOjS+Ly8dKcw2Vo6tLe6S9HnYlSGTFhm2VLYDq5Xs59a7Bzq8OFeDx/7wMjbI5o1s9zcbRZBTgQ+bvhzgqnw1n49DB7gMtJejqgyi36jhSxVw81Dy8Tw/GEKkvG1vqH1jX18kwS8lRp0XP2Qfx61pdUg9UCQUAcGCwey41Qo4ja+/QFqLXIxtiGQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0745; 31:Pw6KGUoZXsd6+9tjpKGF04+TwhX84zCPDnrvf7HwI/wUW2hjfVsijXQrapK+ao10pzXu4BpDKK46X+MwUyax1yidRQum1uownaODxKx8oCnKZQDe2kqoXwTAkZ4vIuMXGLqvQ9thYlL7sbcoualCTWGWz6XApUJ8YEI/FxnCqqME5c6N38RkcFXmbvtKyM4oLP3GKuwcdfcY0BtCllmWGgddbQe/Bk15sEa8BmPb4qKuqYGdyAg8e462xtsVBg5H4zgFGgsku8eKDJxU4JPUfw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(185117386973197)(788757137089)(21532816269658); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095035)(601004)(2401047)(13023025)(13024025)(13015025)(13017025)(13018025)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6096035); SRVR:CY1PR0301MB0745; BCL:0; PCL:0; RULEID:(400006); SRVR:CY1PR0301MB0745; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0745; 4:LRxArm5cBMjB2Dccu/DRijLuLlvKWPKIh9tNi+ntY+QTn2/ql5ggBI9BwfFoYOaWwJI7HI1K0t0F5g8Npr249bS6aqtjEiAxYtsbv82uzDNLseNoIhTrsIRjwdVBxtLaYzYotlzg/mn9zqSKvijIn++Q9F32shYwYWV/rWrtBc3uLldnIbt55dJTYqAtsJEgnhYTYPaPXOJcZgAck2hZeG8QtuAvOsVsf3YVD7f4Zs0ppJTfCdHTe2Ar8lXU508CsGSF5SfBTLIxosvCIY0yWWsmzyy5oD8fSAm9hGQYpi8ecVQPSvICg4KPY0ReIQY1QHUAJiLYraCYzmc60B9mWZ9xAMIrpXyc+xjzoEQ6gaT2h+aecZdids/G/BTjJsmu4/u/zaOj14uvMzJ8cdrQk0EQa4p8w6KdBGedtPe2j7/DU0vJCkNzvsYBY9mdEftNgjEPacRgCJ5kfsRxALwgEdpMK5GbqNzjwHpluQbNXZLXAW1MqlS91ULzhsTVi9W9gNGZFRC9bLBA86Oaw2Buxl+y5jYnyie0+w8FfMT3w2quliznaaOiGM1IaCEQCASjtueGctbr44GHOKv0Ene9kuXEygskOo7MeRv6QRKNaUHTlUq8q7fNYtKRY76nOq6sWaQTItJIyqE2gf76uBt4zKqsszPeHaucKmcTlcJyNC4= X-Forefront-PRVS: 013568035E X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAzMDFNQjA3NDU7MjM6K2p2R0puUm1zbjlzZnhmeHpBazQ3OVZW?= =?utf-8?B?dVFabG5naHdkRUc0MVF5K1pwRkZIeTB4ZHBZOGtZbjZ1WnNaQTdlUGo5b2Ra?= =?utf-8?B?QTJYZnE1N1JrSjIvQnJRdkgxM2NTWW9CeW9IYmlWbHNlaS9RMmdqdldHNkF2?= =?utf-8?B?eWIxT1lITm41ZkVMVGxHbDFXblp6dlBEL2tMNElDeVEvejJRNnhKM3l2NFNM?= =?utf-8?B?NWJHQ3NvUmdCcEdxR1dIZU9XY0x0cWZmRWs4WEx0dHU0YTdPMXNaZGltMmNk?= =?utf-8?B?N2w5QW9XZzUxNWg0NHQ2MUIrMnBGT1AxRWE4ZWVqTjRUVllvRDNUeklieVVm?= =?utf-8?B?US9OaHdoc2VyRVdKRlZTTUE0cG5IdDdLZFl3M2pBMkJRSWhFWmhuV2tQdk9I?= =?utf-8?B?dHZsdWxYUjl4ZmhxaTE5VHl5OTNXR1NFTzlnR2lDdlYxTFlnL0hGbStDa3Vh?= =?utf-8?B?TzBiTlVxYmJRRFdKVU5Oc1V3ci93UmRuTXA1VEFxRC94TWVnMUJkdDlJOXA1?= =?utf-8?B?L2RVMWpmdkRWNW9TR3QwYXBZMzUvbjNwS04ybmFNbkdTV3pPYlZxZ2l2SVkv?= =?utf-8?B?eEk0Z2ZOQ3hHSmllRkZ4Qm1tS1U0NVFob1hEVituOTRuTEhkZzdUSi95SW15?= =?utf-8?B?T0JkSGhaV2xnTXhMZHV2ejRDZFlRTVMzZTVPY1VGUFRCN00rekhsNVVpemd0?= =?utf-8?B?OW9CNnViUm12b0hvOHVQUzZZc0R0Q0pQV1RPYkw2QlZBazRwTWN5MmpaSnRO?= =?utf-8?B?dkFCTXREbTBlNExPbmZ2OWU3VXFNZkFEUTRXWUovN2h2WW5OZVJEdTc1eWtz?= =?utf-8?B?VkNpZ3JSeGk2ejV4ZEwvSnV0dHR1bTNUbWp5VXhjYzcyNFFTdUhBbzJEVzNH?= =?utf-8?B?MDFGS1UyMFhyVGZoUWVwNi9zWmw1SEpLeWc1MzFZZm5DN1R4ZkFpeVA0S0xL?= =?utf-8?B?S1Npa2w0Q3B5K0hMZktPbUNPMDJ2Nm5zclRvT0wwYWRPUlVTZVBnV0VteTNs?= =?utf-8?B?UmRnUmxOalpXbUd6MXlieTZRa2o2L1kzcG5jdDliNU8zaWJ1K2FXNlpRNHkw?= =?utf-8?B?SVZlNThMUHB6ejVSTlVFMW56azJ1M1JLL0hKbFNGYkxvUVdMU3cyRFNuTGlk?= =?utf-8?B?WS9JdUYzblU3emVXRTZGUmg4bVVjRlcxUVp1ZU95MFlFSkErK2Y2c01FM0FZ?= =?utf-8?B?bjc0Qi9wVHhYVHY0dXJUd05oTWtsdzFJWlhTamlEb2IrSE9IcmZHRTR3THI5?= =?utf-8?B?d0R5ZnlCKzN0NlJ2c05XMTA5QjNpNzA0RDlPYmg0elNMM28vTEtaYmxsTHM0?= =?utf-8?B?SWQ0YUkwMlhKTEpJUXVUM3hmQzZHWEorNCt2R3UvaHVnc0ZiK094QzBnQVM2?= =?utf-8?B?RStKT1RPZlMwSTk3WG5SY2dpNFptcitHRWw1STFiQVM1cmJlcVRRQytEZGE2?= =?utf-8?B?Vmc5ekN5Mml0U3dyMVJZbG9LcXowcXdnQVpab0FrNktYRGRrUThFZnJlWVdv?= =?utf-8?B?bGZaRUVwNmVrKzNtQkNSQ0YvKzlBNFZNd3VEOFk2diszeWR1Y0FKdk5PVUJ4?= =?utf-8?B?VjB1c3NCTzNDQW81OFJCMy9kQWVBeWZXS213bm9ZYS9NTTdXMjF4U1FMUlMv?= =?utf-8?B?eTNraFhpcWV2TFFmdWRyR0hTSzRHVGVYSXdEOC80SlRSODkyTmJiQWJIUWR0?= =?utf-8?B?aXAxWjJIMVRQTUhNYmQ4MXp4UWFMSzdrSUNHd1pxY3hIb0V0SXo1NkFLT2Nu?= =?utf-8?B?NVg3aXJPdWNHU0YwQkJ2YUQzQmU0ZHVKZlFha1VqeTZ2Q2pFZVdsNmIzSldm?= =?utf-8?Q?IMQUgIQUrpg0FPh?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0745; 6:D0LvZOF2lNljziK8Dv+iFofJdQH5IsWaXzMWQ01Ed3BQ5c9UyRCjEkZlxPL2eeRbLieAThi/eI7ivJ3ymC2NzeJWM84FH3WWhQ5CcgVcQ5ALxOzMSyrOkoYV21tQDNa6UVIGer88Ou2ZOiwgLXeCpqrr5zWC/ZjGDEi0AQ2/ExPOIvrcMtF5JA9/jTCV69jvDdNdYyFUyxWTFx1nwKKmNlNfn4IyKkUt6o0J1V4cpFph0QuDGh2peVcGJW3E9sR3SCuOc50Ux6AbvsLxdi3NUSLubrfbZRwVpi0+MC6Dq4NjHLzAqLJgKNE9QQ7e+PiVulotccEodW4dl5k+cjUTlA==; 5:m+/cL/5dOOWbrcDfjcFW2VTPbXp25mg4YS2HLevhYSf1eiIjRru69RB0TKKbE/ZUEGrpF6PRj6zzLd57zP49dIKLnBPFJjkBVWk/GTWppcuvK2yiW2ykRada7wLlsC35Fb79MGYss7iHdu9FEuqoFyeZs0wXdaSIzoekyEtoCwtVgjXAPEig5pRt6AUBfeFs; 24:PKzjItlcW6LfRPUTqM6HAIkdDKjeofV8skCfYb6o7Ep24Pyv8BMwECqRjYMm8b3M+e5eNfTDn/ELyEI11l1j6Wa+D4QGk68/qgD1xq4mn6o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0745; 7:Rq5sQqZOVmEw2YgfvHVH5zHpYkAr7CrJh82nmEhWwBqtSIwTUSsZUPM+mOsWw84CxMO4J6+H8j/lGTKfgvrSAODVjvEg721kzpAd7XwmjZIqcYr8Bgjo/eEJURTqjMdvMl9UD3sd7wan2VVetQV0RetOQCg1amN/kFNxRD1XcloJ5GIAK9nr/0tRMc08phlu1Ld7FjjtPex1lwGEBl5f3AYJc7rGZwORXQ1Zd2LBiP3BD3RZ3U33s76nVe+lEY/djtQsMAeGtmIFNUmO41ADDiEN/2fXUfAIgUtG0op1aJTa7uJ9DbiRW2m18p57aWptoAuQruqhzobgWmrOeFNERvBKDEOgF0tnwqYg4CQ85uo= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2016 09:42:50.5176 (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: CY1PR0301MB0745 Subject: Re: [dpdk-dev] [RFC PATCH 0/6] Restructure EAL device model for bus support 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: Wed, 23 Nov 2016 09:42:54 -0000 I should have replied to this earlier, apologies. On Sunday 20 November 2016 09:00 PM, David Marchand wrote: > On Thu, Nov 17, 2016 at 6:29 AM, Shreyansh Jain wrote: >> DPDK has been inherently a PCI inclined framework. Because of this, the >> design of device tree (or list) within DPDK is also PCI inclined. A non-PCI >> device doesn't have a way of being expressed without using hooks started from >> EAL to PMD. >> >> With this cover letter, some patches are presented which try to break this >> strict linkage of EAL with PCI devices. Aim is to generalize the device >> hierarchy on the lines of how Linux handles it: >> >> device A1 >> | >> +==.===='==============.============+ Bus A. >> | `--> driver A11 \ >> device A2 `-> driver A12 \______ >> |CPU | >> /````` >> device A1 / >> | / >> +==.===='==============.============+ Bus A` >> | `--> driver B11 >> device A2 `-> driver B12 >> >> Simply put: >> - a bus is connect to CPU (or core) >> - devices are conneted to Bus >> - drivers are running instances which manage one or more devices >> - bus is responsible for identifying devices (and interrupt propogation) >> - driver is responsible for initializing the device >> >> (*Reusing text from email [1]) >> In context of DPDK EAL: >> - a generic bus (not a driver, not a device). I don't know how to categorize >> a bus. It is certainly not a device, and then handler for a bus (physical) >> can be considered a 'bus driver'. So, just 'rte_bus'. >> - there is a bus for each physical implementation (or virtual). So, a rte_bus >> Object for PCI, VDEV, ABC, DEF and so on. >> - Buses are registered just like a PMD - RTE_PMD_BUS_REGISTER() >> - Each registered bus is part of a doubly list. >> -- Each device inherits rte_bus >> -- Each driver inherits rte_bus >> -- Device and Drivers lists are part of rte_bus >> - eth_driver is no more required - it was just a holder for PMDs to register >> themselves. It can be replaced with rte_xxx_driver and corresponding init/ >> uninit moved to rte_driver >> - rte_eth_dev modified to disassociate itself from rte_pci_device and connect >> to generic rte_device >> >> Once again, improvising from [1]: >> >> __ rte_bus_list >> / >> +----------'---+ >> |rte_bus | >> | driver_list------> List of rte_bus specific >> | device_list---- devices >> | scan | `-> List of rte_bus associated >> | match | drivers >> | dump | >> | ..some refcnt| (#) >> +--|------|----+ >> _________/ \_________ >> +--------/----+ +-\---------------+ >> |rte_device | |rte_driver | >> | rte_bus | | rte_bus | >> | rte_driver |(#) | init | >> | | | uninit | >> | devargs | | dev_private_size| >> +---||--------+ | drv_flags |(#) >> || | intr_handle(2*) |(#) >> | \ +----------\\\----+ >> | \_____________ \\\ >> | \ ||| >> +------|---------+ +----|----------+ ||| >> |rte_pci_device | |rte_xxx_device | (4*) ||| >> | PCI specific | | xxx device | ||| >> | info (mem,) | | specific fns | / | \ >> +----------------+ +---------------+ / | \ >> _____________________/ / \ >> / ___/ \ >> +-------------'--+ +------------'---+ +--'------------+ >> |rte_pci_driver | |rte_vdev_driver | |rte_xxx_driver | >> | PCI id table, | | > | other driver | | nothing> | +---------------+ >> | data | +----------------+ >> +----------------+ >> >> (1*) Problem is that probe functions have different arguments. So, >> generalizing them might be some rework in the respective device >> layers >> (2*) Interrupt handling for each driver type might be different. I am not >> sure how to generalize that either. This is grey area for me. >> (3*) Probably exposing a bitmask for device capabilities. Nothing similar >> exists now to relate it. Don't know if that is useful. Allowing >> applications to question a device about what it supports and what it >> doesn't - making it more flexible at application layer (but more code >> as well.) >> (4*) Even vdev would be an instantiated as a device. It is not being done >> currently. >> (#) Items which are still pending >> >> With this cover letter, some patches have been posted. These are _only_ for >> discussion purpose. They are not complete and neither compilable. >> All the patches, except 0001, have sufficient context about what the changes >> are and rationale for same. Obviously, code is best answer. > > As said by Jan B., I too think that splitting the patches into smaller > patchsets is important. > > Looking at your datamodel, some quick comments : > - Why init/uninit in rte_driver ? Why not probe/remove ? No specific reason. At first I wasn't planning to replace driver->init with driver->probe (which rte_pci_driver) is doing. But, I will do this in v2. > - I don't think dev_private_size makes sense in rte_driver. The bus is > responsible for creating rte_device objects (embedded or not in > rte_$bus_device objects). If a driver needs to allocate some priv (for > whatever needs), the driver should do the allocation itself (or maybe > a helper for current eth_driver), then reference the original > rte_$bus_device object it got from the probe method. first off, this came as a suggestion on the ML somewhere as far as I remember. Secondly, your point makes sense. I will move it back. > > > For a first patchset, I would see: > - introduce the rte_bus object. In rte_eal_init, for each bus, we call > the scan method. Then, for each bus, we find the appropriate > rte_driver using the bus match method then call the probe method. If > the probe succeeds, the rte_device points to the associated > rte_driver, > - migrate the pci scan code to a pci bus (scan looks at sysfs for > linux / ioctl for bsd + devargs for blacklist / whitelist ?), match is > the same at what is done in rte_eal_pci_probe_one_driver() at the > moment, > - migrate the vdev init code to a vdev bus (scan looks at devargs): > this is new, we must create rte_device objects for vdev drivers to use > later Thanks for outlay - I agree with that. > > Then we can talk about the next steps once the bus is in place. I will post the new set probably tomorrow or day-after. > > - Shreyansh