From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0064.outbound.protection.outlook.com [104.47.38.64]) by dpdk.org (Postfix) with ESMTP id 5A05491AA for ; Thu, 8 Sep 2016 09:09:58 +0200 (CEST) Received: from BY2PR03CA068.namprd03.prod.outlook.com (10.141.249.41) by BY2PR0301MB2008.namprd03.prod.outlook.com (10.163.196.30) 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:09:56 +0000 Received: from BL2FFO11FD038.protection.gbl (2a01:111:f400:7c09::117) by BY2PR03CA068.outlook.office365.com (2a01:111:e400:2c5d::41) 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:09:56 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; networkplumber.org; dkim=none (message not signed) header.d=none; networkplumber.org; 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 BL2FFO11FD038.mail.protection.outlook.com (10.173.161.134) 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:09:55 +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 u8879r8X005736; Thu, 8 Sep 2016 00:09:53 -0700 To: Stephen Hemminger References: <1466510566-9240-1-git-send-email-shreyansh.jain@nxp.com> <1473257297-7221-1-git-send-email-shreyansh.jain@nxp.com> <20160907114004.4a218155@xeon-e3> CC: , From: Shreyansh Jain Message-ID: Date: Thu, 8 Sep 2016 12:40:08 +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: <20160907114004.4a218155@xeon-e3> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131177921959692910; (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)(199003)(189002)(24454002)(377454003)(31696002)(23746002)(356003)(8666005)(5660300001)(19580395003)(7846002)(19580405001)(33646002)(11100500001)(106466001)(36756003)(65826007)(110136002)(8676002)(105606002)(68736007)(305945005)(81156014)(81166006)(8936002)(50466002)(189998001)(104016004)(77096005)(15975445007)(97736004)(65956001)(586003)(92566002)(47776003)(4001350100001)(86362001)(83506001)(64126003)(85426001)(65806001)(575784001)(230700001)(54356999)(15395725005)(626004)(5890100001)(31686004)(4326007)(50986999)(2906002)(87936001)(76176999)(2950100001)(7059030)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0301MB2008; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD038; 1:og4IehCAAbuT0gMAT49iZOUKP4G0xoySXahA5SluobBTf/Uep5C8MR5D0uS08vA1oB6JYUMZIVUD4I/LyGfIl+InLym05QAgneDdz15hXWK9b3Fh2G+mz+XKOrqZi2coIx+1bPiE6etWJCmLMJMaeiqJ3ScZ3Yvz/ZwNK9EngbyTTV/nDIECkfpE3ho9uNcy1vFAh9ikzsyUH3UifddrNJ6E54mCEs315fsZucJK68GYdn6LeQIxli2aFNMYapuHxninoI2nNEx5wkHml+V1MRQlM32kI4NyASfyAusTjo54ZivFBdFY7cG+4VsbRtFso4KGUcqV4r9jptYxCaPkFyJyuGTdRP4skT7JaAwGHWa7Ebq3/Ne2Tnre9AnNGng89qmXAd6F3OLntaPkHVi4RRu8hs33a7CTAWeuUx+v8fJnicdmLzeYgMFCSyjvVjyCW69m7ldqPT2l9PxKw+0yIHDZfp4d2/4NezmF0nAq5iFpN73yXg59MY44/PXvzI98aBl2ko1u+ZIOm6zPmvj0F9PLlyHesrDZ4j8o630AQfqgiMtuWwT+cDMub2hQuIMV/Dx4gIE0x5mdbqn0XeK4Cw== X-MS-Office365-Filtering-Correlation-Id: c5d3a940-9205-4724-a90e-08d3d7b7233c X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB2008; 2:6JS2kgpHR6d1kJgDnXVKpbdQBfX4CtP7UDMv6y+0MKWyMHE8/Y075q0NQM2j4o3d/wd6nDrWHJPmNDGqrbr8KTx8/6qG5cszA8RqB77qVZHUucZjv1RIRuyCJqQ2F5C5pg+cbhcBTfNkZlvBVsNCwwx+ktvG3cWCdUaJP9uPr0ZHOcZyYBXUcMmCXj9XNdRG; 3:OQBTmEZTuqrnyuExcx5Es0OpI73yUKX8Zi00XJWZDvWcLXvDXZiJnQ96n7qmSgtZ4qyRfYv7Y4E0THAO34yzavHetlK7X2GOvnS9hBmxunHhV82jpXHTYscGCPR1ODLUqdbdhhA9PjeIjW3o4xqRj+xZo+xEjacm1hnDWgIuKRUGvPXl5gUr3bCGCBxWPuCqJxCHzHI12o93nLcPZcMNDIQuylbtv9koa/Luk7NXk8U= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB2008; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB2008; 25:69+2hKQcC4nglWYtsRTzKm75bv8kNtsdlTDYyGq1qA8zUL5ZJR0o8IdJ0pyiJ2JCbdyka8NxykuO3JltxNNkpbvHHl3bdaVTBqjNesAx9fdOj644DWtEsFaCZDUjD6PH/z1uf6lNjhBMcSlTP7D+MqOwzt6kIxG/yJx+p1ZZM/ofYZVrZJ63xZT9PxCsvyJA4DQcYHpJWJNYRDihT2rSnBlaYx61riOUptUJ1f5zpBkN0VfGkov2gclVo6ND+ttt3VVQWcl5yGukMBoFUbyd4Byv6mS2aAXHjOZpU+xG0fIZs6H9QCWliAlixJVPYXZjAywwANIJXbWah9kfFMiMXks/451iumaektJ3D5Oo+9/PRhTRo2z9TjAXw2Xgh164+GZ+bmgYgBMNw80BaERCsSo/e6dR3CCgCJxH9l32n5wk5J84JNiBxXS7zGg67b0z+Ku4ExJ5PHQFIvvOSD86ljiYOXBrAJNP7J/opeVoVI4zo4XtErF3ECH5P52ckc5DLlm6UWjtIdVu8S7oMhjVy3i69RXPkgIdXsruJAOxKz+lfabw24ZNJKOPue4JF4fxZNdl7bCO8rg5IkAO7iTVzq8YuMBKseL5HTJD/e4DIUqkdphMWsQsxyuX008HfOHV8VUOEJ0aMvdv5DVdRBc4kD6vikFRhPmSV6j6Wqmo4sWBYI5EjU/eUBWR7I24SU9FxPYzLTEV1ZlbyUySCoTBON1MCFz3puLAFnNoX+fB3L82/SjtQa8QCoRpzTcV48Q2ztt/l9bK/B/SjEHFFnTMHLhtLyLmbALszdhs0QwhQVEvP/iLmOnl0dWcsOrJ85uErdRsZC49Jqai06Q+qhydDA== X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB2008; 31:Y7OurJ2IWHnadoFW5Tr5mg965cxReKY2mMfPZTdocB2J2JLIa/+a5xeuQTtUu02ASHlG5GU4bDh4jCWIh1X0/+X1R5DIFlrWpbv/tkLwgRKhDlv2wQsh4XE+n59vzQAuPeqX5NBQcWZ9pNeiFdbsbldngylJRktSvj04iZNxMx2KW8mrpaVlg51Eiqp6wsNzJ8EBHdIvndfTCOwDKTG26IoJDGhbYDATYan9/2B6ZiY=; 4:PkdEwmGyRS1Oazra9S5Dju0blYVXbWZzJuzDLdCkIC1aHCmbXk8/IYkRGu6eC2iJ75rO84oRA704+G281EOdR1is7c/OVNl2df8sv0x3coD2CJT9F5gTVKvs7+bBC6TuUPjW7s12y21hRNflv8IwMklOjbzEza/KiOLV0lLrEMmVc/RTf2gnVHQ2IT2N5qvw/B3kuVrNPEgbZd+b+SWMik4mTf6kMpvNiRnnHE7WEO97EfvGgSeEXfQXY2+QPD6w2p940kCS5edTBjBmTbo579zrZFfJiULfpH7BirjKA/IFA0eHJ4dm8XqefHOPVOeKFvNT9robn07ZAR3DaOX7t57T7VtQ+VtqMja/sX1Nbz+oR+HvB8gcTm8G76ktHT7KppcjIO1pO5UltPOQ73AONH7NTG3GybrBgsdOhXCSJyxq12JN+0I0/KT+QT5//V1gbhz5dFLczaxrUzNEro4mssbpx0ORifrGrz+9+4DSJXEkuD36heTPN9eh1pJFCzyuXI/pZ48+enp0y9KJmIGyF7Kka41uxT+d8T8O7o+scb0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13015025)(13017025)(13024025)(13018025)(13023025)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR0301MB2008; BCL:0; PCL:0; RULEID:(400006); SRVR:BY2PR0301MB2008; X-Forefront-PRVS: 00594E8DBA X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR0301MB2008; 23:v6NtULUADFUmbrBcJ5hWwQle0yv105NNF1u?= =?Windows-1252?Q?mb0K5A0bjj//DKrx2dq8RoS2eclG9Su88Eeta0SzTdv7VtwubLpPQSwX?= =?Windows-1252?Q?bunoVTuTX7RGU4jagF4YEMuB0VcQjvVyb7SDKnhoY2Wgc3cFibTvhKLt?= =?Windows-1252?Q?Zvs4yRZq6JRoBGObcuBNe/FR5j18AD7NUUTsjPx2u+Ik1Nt4va4ckjh3?= =?Windows-1252?Q?gQh0hYvPIAsuccZqPYIMjW7YYKDvhfs53Ap6BH04N7/SFItfV+RquHAd?= =?Windows-1252?Q?1w4Q98osAKM8K0vMvv1w+sWZmFsKxubkZ+U827T0Dp6YWbaxDkvlmewy?= =?Windows-1252?Q?clIsKWkERizd5PXrxI8KM/1pD7Dqz68o/kQQiPG1n+0usBQwO/TIefGN?= =?Windows-1252?Q?AFiz7YVD2CZ6hjalXO0aWQ9XRalBhQ7/FVuViW/cY7L48DXTqimMdX+y?= =?Windows-1252?Q?QgnlEjFP2fn9rK6XVWs8mAN+DXgWK7aR5xwCMXIhBt8b+itmScWeU4H2?= =?Windows-1252?Q?UhlyFoi8Ulew6MYrJ27a9zv0KzPjbTN48RGoI49Mbi6+ayWFx/15m3Qr?= =?Windows-1252?Q?tlYGeBAEQ1c7jZBB9TDkjbTAQJueemvHvQx9Wanm3jDAdw8yUSaw7Hpg?= =?Windows-1252?Q?OoaJg/el6pJolosC5UU/VDt5avyl//OUJjN8DcCZdvR45KDzhJkZbHmS?= =?Windows-1252?Q?4YlSNHnr099jPHYaWAjnl56BZJhMYbLuXNkHXQEY81P6cZYAkmmsvjK0?= =?Windows-1252?Q?V1Ibf/jUSojzSCBx758fZdM9gToL7IVPsACQQDUK3ffcp1wUzKTeoixF?= =?Windows-1252?Q?C+1bud4XCE3rLrXKmclm9trDRW4Pg6sPjQu0NuET4ag3gfvz7pRT1MgY?= =?Windows-1252?Q?GOZE6ViH0NvsNfNsEwrxDv9h1ZG3pdkobU+901/Pwae9ouTmcqnKjZrJ?= =?Windows-1252?Q?q4m626CCTUehExLiOpf9gfwsGkHwPsIwAoFNw0V04GtPBg50cGzrLBQo?= =?Windows-1252?Q?v/LGlNf/adarxvFNYpOfqBDB8I8fSkz4xRdZKdkvOy1TF+MTgGiRDod5?= =?Windows-1252?Q?7ci00jVRqG7Q+jtF5DO3KnUZDb8JpUg/KK3f2XjSeAShOBRj+ehNYp6e?= =?Windows-1252?Q?YhPIymGbv2h0pY+ToZ9l5sStrh9JxD4R3jQU42yjR49CaDpEoR/KycPS?= =?Windows-1252?Q?vDbi4p1cJAoTfmR5Rp0oNQ4JNJNbqy6cdMz0h1INBveq8vcIZy0cMw9Y?= =?Windows-1252?Q?zwQS4LbIxH+jbC+uJRd/t7rtYHLScOxjGHsbuVg6x/d9lULCEnA0aNzw?= =?Windows-1252?Q?vVTekyXRnFe5mmJurXP+3nvMTdCaRVO9IkrYpAKTm8YRuW9o6YfGFx1K?= =?Windows-1252?Q?iy7AOKhUr9/3EUPJl/KUVdI3Jji4CZnLSTXVYJ1NRyG5yaQZArYaSdG+?= =?Windows-1252?Q?A4NUGDw26+jI7cq3W+BA6G96C0NNAOZPHXIV/mfb9sa9r6kL24HkHRDl?= =?Windows-1252?Q?yffXlHUjcLeRglUTm2CLnBw7wyyO6FPWzifK/2kkKGvMjud+H/m7jMAB?= =?Windows-1252?Q?Guh7oKy8gDqMYz8ovd9Ii9/OhTMwz188lN/zGsOWAGRqHcTtQ5zIl6eC?= =?Windows-1252?Q?qIA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB2008; 6:/mU99PQE9POiNurV8MpkuPfoCEQUgbIf1hnnNMHXaxh3z3aiy5s3kWy0yIDnxikTiGXLsqW2uj8KtudL/JzDkz7kL2hyixeL5+ptQTLJEQ7MzT/xXLQYBU8Q8LC+6qrlXF5KRPRhJm8cJQrPvHxRVGcu5J7o0Ckb1l4WlZgKBI0MgGvrPabPHdWxcUT4doseH+q7Ax5RHmUbIkHVJatBdRCjAWA7Pfru1CRYHG2o2tuv/U80mvMhHzoIvlQb6qsVCAiiWfHh+qefdjJU21MeW9rEpzciM7AMlgayHSkNNW0=; 5:WxZvnEdGy5jdjT5nRHnW4uKigyVKQUA75vF8Ts8L9ZdJ0rxmjzBsdKHGWuH+ql7FJy2RPqVHUNBESyWM5WeSTJTu7SuheLLLMjNd2/Kh/VuZTYnhIUrxBFj2AHRRAKWM+eYjEwZLYul9J4muplmS6L+ckJ/bhS7YqGW1Fqn6h+k=; 24:HpuiFPj+if4kP4N3ms0wK3dF7bVRFFcANwIICpBoZDSRrq6YBNplldCddfE09k5BxcTgIMIgadNYhkzCM8p4ekZWgBu14Kd6OTD07JDgiBM=; 7:17v3zf3mJES9OaRx899krDaPDB0EbVt0QZLIRCm3SRYgAlM+gU+7mXuVfWtqXQAB0iJrsLi1KPyYLkoHmqWOgNEtUPTOLT3svQc0e5iVqY04e+ZHoK6Sn9OdbCfQ99UwylZUVtvnEQWkAWAyPq8DnzrlpSRffN1Vis5y/6jmwUbvc+X1nKmPTLyInzYUiW1WB/nukBQlSk37k4e3tkcJa8w/T9aWzYkTONflym3tOWZRRgK0vvr9IOagWd8xc4qz SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2016 07:09:55.7820 (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: BY2PR0301MB2008 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: Thu, 08 Sep 2016 07:09:58 -0000 Hi Stephen, On Thursday 08 September 2016 12:10 AM, Stephen Hemminger wrote: > On Wed, 7 Sep 2016 19:37:52 +0530 > 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). >> >> >> 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. >> >> References: >> =========== >> >> [1] http://dpdk.org/ml/archives/dev/2016-January/032387.html >> [2] http://dpdk.org/ml/archives/dev/2016-April/037686.html >> [3] http://dpdk.org/ml/archives/dev/2016-January/031390.html >> [4] http://dpdk.org/ml/archives/dev/2016-July/043645.html >> [5] http://dpdk.org/ml/archives/dev/2016-June/042439.html >> [6] http://dpdk.org/ml/archives/dev/2016-June/042444.html >> [7] http://dpdk.org/ml/archives/dev/2016-July/043172.html >> [8] http://dpdk.org/ml/archives/dev/2016-August/044941.html >> [9] http://dpdk.org/ml/archives/dev/2016-August/045947.html >> >> Changes since v8: >> - Some review comments from Ferruh Yigit & Reshma Pattan have been fixed. >> = Though changes in mlx4/mlx5/szedata2 have been done, I am still unable to >> verify those in absence of a proper environment at my end. >> = Comment from Ferruh for eth_driver, drv_name are not fixed yet. >> - Added a 'Future work' section in Covering letter >> >> Changes since v7: >> - Rebase over master (e22856313fff2) >> - Merge the patch series by David [1][2] and Jan [4] into a single set >> hereafter, PCI and VDEV, both are re-factored for rte_device/driver model >> >> Changes since v6: >> - rebase over 16.07 (b0a1419) >> - DRIVER_REGISTER_PCI macro is now passed pci_drv rather than drv >> - review comments regarding missing information in log messages >> - new API additions to 16.11 map objects >> - review comment in [5] and [7] are not included in this series. >> >> Changes since v5: >> - Rebase over master (11c5e45d8) >> - Rename RTE_EAL_PCI_REGISTER helper macro to DRIVER_REGISTER_PCI to be in >> sync >> with DRIVER_REGISTER_PCI_TABLE. [Probably, in future, both can be merged] >> - Modifications to bnxt and thunderx driver PMD registration files for >> using the simplified PCI device registration helper macro >> >> Changes since v4: >> - Fix compilation issue after rebase on HEAD (913154e) in previous series >> - Retain rte_eth_dev_get_port_by_name and rte_eth_dev_get_name_by_port which >> were removed by previous patchset. These are being used by pdump library >> >> Changes since v3: >> - rebase over HEAD (913154e) >> - Update arguments to RTE_EAL_PCI_REGISTER macro as per Jan's suggestion >> - modify qede driver to use RTE_EAL_PCI_REGISTER >> - Argument check in hotplug functions >> >> Changes since v2: >> - rebase over HEAD (d76c193) >> - Move SYSFS_PCI_DRIVERS macro to rte_pci.h to avoid compilation issue >> >> Changes since v1: >> - rebased on HEAD, new drivers should be okay >> - patches have been split into smaller pieces >> - RTE_INIT macro has been added, but in the end, I am not sure it is useful >> - device type has been removed from ethdev, as it was used only by hotplug >> - getting rid of pmd type in eal patch (patch 5 of initial series) has been >> dropped for now, we can do this once vdev drivers have been converted >> >> >> Shreyansh Jain (25): >> eal: define macro container_of >> eal: remove duplicate function declaration >> pci: no need for dynamic tailq init >> crypto: no need for a crypto pmd type >> drivers: align pci driver definitions >> eal: introduce init macros >> driver: init/uninit common wrappers for PCI drivers >> drivers: convert all pdev drivers as pci drivers >> driver: Remove driver register callbacks for crypto/net >> eal/pci: Helpers for device name parsing/update >> ethdev: do not scan all pci devices on attach >> eal: add hotplug operations for pci and vdev >> ethdev: convert to eal hotplug >> ethdev: get rid of device type >> eal: extract vdev infra >> eal: Remove PDEV/VDEV unused code >> drivers: convert PMD_VDEV drivers to use rte_vdev_driver >> eal: move init/uninit to rte_vdev_driver >> eal: remove PMD_DRIVER_REGISTER and unused pmd_types >> eal: rte_pci.h includes rte_dev.h >> eal: rename and move rte_pci_resource >> eal/pci: inherit rte_driver by rte_pci_driver >> eal: call rte_eal_driver_register >> eal: introduce rte_device >> eal/pci: Create rte_device list and fallback on its members >> >> app/test/test_pci.c | 10 +- >> app/test/virtual_pmd.c | 8 +- >> drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 7 +- >> drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 7 +- >> drivers/crypto/kasumi/rte_kasumi_pmd.c | 7 +- >> drivers/crypto/null/null_crypto_pmd.c | 7 +- >> drivers/crypto/qat/qat_qp.c | 2 +- >> drivers/crypto/qat/rte_qat_cryptodev.c | 18 +- >> drivers/crypto/snow3g/rte_snow3g_pmd.c | 7 +- >> drivers/net/af_packet/rte_eth_af_packet.c | 11 +- >> drivers/net/bnx2x/bnx2x_ethdev.c | 36 +-- >> drivers/net/bnx2x/bnx2x_rxtx.c | 3 +- >> drivers/net/bnxt/bnxt_ethdev.c | 17 +- >> drivers/net/bonding/rte_eth_bond_api.c | 2 +- >> drivers/net/bonding/rte_eth_bond_pmd.c | 9 +- >> drivers/net/cxgbe/cxgbe_ethdev.c | 25 +-- >> drivers/net/cxgbe/cxgbe_main.c | 2 +- >> drivers/net/cxgbe/sge.c | 7 +- >> drivers/net/e1000/em_ethdev.c | 17 +- >> drivers/net/e1000/igb_ethdev.c | 41 +--- >> drivers/net/ena/ena_ethdev.c | 20 +- >> drivers/net/enic/enic_ethdev.c | 24 +- >> drivers/net/fm10k/fm10k_ethdev.c | 30 +-- >> drivers/net/i40e/i40e_ethdev.c | 31 +-- >> drivers/net/i40e/i40e_ethdev_vf.c | 26 +-- >> drivers/net/i40e/i40e_fdir.c | 2 +- >> drivers/net/ixgbe/ixgbe_ethdev.c | 48 +--- >> drivers/net/mlx4/mlx4.c | 21 +- >> drivers/net/mlx5/mlx5.c | 22 +- >> drivers/net/mpipe/mpipe_tilegx.c | 18 +- >> drivers/net/nfp/nfp_net.c | 28 +-- >> drivers/net/null/rte_eth_null.c | 11 +- >> drivers/net/pcap/rte_eth_pcap.c | 11 +- >> drivers/net/qede/qede_ethdev.c | 42 +--- >> drivers/net/ring/rte_eth_ring.c | 11 +- >> drivers/net/szedata2/rte_eth_szedata2.c | 29 +-- >> drivers/net/thunderx/nicvf_ethdev.c | 21 +- >> drivers/net/vhost/rte_eth_vhost.c | 11 +- >> drivers/net/virtio/virtio_ethdev.c | 28 +-- >> drivers/net/virtio/virtio_pci.c | 5 +- >> drivers/net/virtio/virtio_user_ethdev.c | 10 +- >> drivers/net/vmxnet3/vmxnet3_ethdev.c | 27 +-- >> drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +- >> drivers/net/xenvirt/rte_eth_xenvirt.c | 11 +- >> examples/ip_pipeline/init.c | 22 -- >> lib/librte_cryptodev/rte_cryptodev.c | 71 ++---- >> lib/librte_cryptodev/rte_cryptodev.h | 2 - >> lib/librte_cryptodev/rte_cryptodev_pmd.h | 45 ++-- >> lib/librte_cryptodev/rte_cryptodev_version.map | 8 +- >> lib/librte_eal/bsdapp/eal/Makefile | 1 + >> lib/librte_eal/bsdapp/eal/eal_pci.c | 54 ++++- >> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 7 + >> lib/librte_eal/common/Makefile | 2 +- >> lib/librte_eal/common/eal_common_dev.c | 95 ++++---- >> lib/librte_eal/common/eal_common_pci.c | 34 ++- >> lib/librte_eal/common/eal_common_vdev.c | 106 +++++++++ >> lib/librte_eal/common/eal_private.h | 20 +- >> lib/librte_eal/common/include/rte_common.h | 21 ++ >> lib/librte_eal/common/include/rte_dev.h | 77 +++++-- >> lib/librte_eal/common/include/rte_eal.h | 3 + >> lib/librte_eal/common/include/rte_pci.h | 51 +++-- >> lib/librte_eal/common/include/rte_tailq.h | 4 +- >> lib/librte_eal/common/include/rte_vdev.h | 96 ++++++++ >> lib/librte_eal/linuxapp/eal/Makefile | 1 + >> lib/librte_eal/linuxapp/eal/eal.c | 1 + >> lib/librte_eal/linuxapp/eal/eal_pci.c | 23 +- >> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 10 + >> lib/librte_ether/rte_ethdev.c | 280 +++++------------------- >> lib/librte_ether/rte_ethdev.h | 40 ++-- >> lib/librte_ether/rte_ether_version.map | 10 +- >> 70 files changed, 791 insertions(+), 1025 deletions(-) >> create mode 100644 lib/librte_eal/common/eal_common_vdev.c >> create mode 100644 lib/librte_eal/common/include/rte_vdev.h >> > > Overall I like to see the clean separation. > Are you sure you removed as much as possible from PCI? I am not very sure of what you mean. If you are referring to whether all PCI PMDs have been taken care of, I think they are. Only issue being I can't test all of them functionally. I have some steps provided by Thomas which can help me compile test these. Or, if you are referring to whether PCI drivers have been completely disconnected from existing EAL (and converted to above linkage), I think yes. Key change that still remains is delinking eth_driver from PCI type and using a more generic approach where eth_driver (or rte_eth_driver, after name change) can be of any type - PCI, Virtual, SoC etc. > I wonder of global PCI device list is needed at all if you now have list of all devices. > I think yes. There are separate lists for all device types which helps keep the EAL code free of type checks. But, functionally it doesn't make that big a different between a common or specific list. I am in favor of separate lists of each rte_xxx_device/driver type - other than a global list (which is not actually being used, for now). - Shreyansh