From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0082.outbound.protection.outlook.com [104.47.33.82]) by dpdk.org (Postfix) with ESMTP id 2CBC3558B for ; Thu, 17 Nov 2016 14:06:17 +0100 (CET) Received: from BN3PR0301CA0056.namprd03.prod.outlook.com (10.160.152.152) by CY4PR03MB2472.namprd03.prod.outlook.com (10.168.165.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Thu, 17 Nov 2016 13:06:14 +0000 Received: from BN1AFFO11FD009.protection.gbl (2a01:111:f400:7c10::159) by BN3PR0301CA0056.outlook.office365.com (2a01:111:e400:401e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10 via Frontend Transport; Thu, 17 Nov 2016 13:06:14 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; infradead.org; dkim=none (message not signed) header.d=none;infradead.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 BN1AFFO11FD009.mail.protection.outlook.com (10.58.52.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.721.5 via Frontend Transport; Thu, 17 Nov 2016 13:06:14 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:908; 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 uAHD6B6e032124; Thu, 17 Nov 2016 06:06:12 -0700 To: Jan Blunck References: <1479360605-20558-1-git-send-email-shreyansh.jain@nxp.com> CC: David Marchand , From: Shreyansh Jain Message-ID: <944308a3-8fb8-2c4d-8f0f-04ae48bf334c@nxp.com> Date: Thu, 17 Nov 2016 18:38:28 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.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: 131238615743701337; (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)(377454003)(189002)(24454002)(199003)(7846002)(92566002)(305945005)(31686004)(81156014)(2950100002)(626004)(33646002)(31696002)(36756003)(356003)(4326007)(229853002)(2906002)(104016004)(23676002)(65806001)(86362001)(77096005)(50466002)(65956001)(47776003)(64126003)(15395725005)(87936001)(8936002)(85426001)(106466001)(65826007)(50986999)(189998001)(110136003)(105606002)(4001350100001)(230700001)(5660300001)(6916009)(54356999)(68736007)(8676002)(97736004)(76176999)(83506001)(81166006)(6666003)(21314002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2472; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD009; 1:Kw5gjmBZzWETXwjVFUHMp9uwYrkNRC8ASwJpH+c8IMvHRAg3bGW4HB+KzLbtsZlC5kET4OHGR/NB8UkyH9/x7iGYcbwxasudUAY4AXknhejUkMm51g+ZZZFOGR/kj+OXGnuuquovOesUfGOe1IXakdtYWcbyBbsxQfAWMpeRTaZh4pHQss0LWBAbaEhLxK14cx2n2jJCFLc8JxOora6WB/CUY8hntSPTJ9XmnWX4I3frrzifxrmr8cdfx+nPCWEekxel1tBgqijIOqWk7Zxq58pUB3olQLSPOtTlGw0aDjwIvgvJEcAbE4QGj3ZQ6RArepN2q1GSN3lSxqJ9URYNVNykiv+oG3bKJdAL+Mle0tcy9fc0Kjy/LeJlw4jIdGWktJFfbXLqTFePdzLv4T6WbzbBymdruURl8yImcFmmQlmHS3bklL8uMllSAYqduGDooh1bUufCG4e8idiS1tWgt3zDGeil37YAkB5Wq8RtSS+AOetITriQLIHxlh+HMZTbEWHFUCX1bCOaw3qD1TXTLcJX0tCgaF+yiXTk3vZi1AmIf3W35EYAAgmiCA67S2fbUHTgjQcsqm4f0JU8BgwG2EhSEw2KhXDCwdOEtryV740= X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2472; 2:oIuQxOgEbvlS4fP4YbPd/toMjm75euRApmtAzDlA32Ay6CBnGJSdLcuUY1yHeahyEzDtZR7yfJ6kV1/UBI/GtyhD2UhS/09jkbKRD9szIq8u/p2NORFGim+cE1ZS2EzwFDFBXUvaCGIN+UBE2lF13RGfi7aLoM0NP9Sjk3KYOfA=; 3:R0XFrhMB98uSx2g/Qifx46E0kBhNNn5IL3HqkNABI6PbqDScx3bLbKFMvTtR+rsd9brewLT+MXJuXOyaMw/kmzUddxoQPAWIiOnvQ3MtsteguZWi+3R5DVyGbosRqWQAQjlJMPe2CK95mF5xcCL61RNjBJTxfT0VA+zdC17at+eqwqquqSiv1BPIch3X/lcJG3D0yxJNrGhPWBXIL37YAUWrqOLhYDDY+80lc7VMrVFWKM9C4N/yMj+qwcChm0KWDklRUEclui5yPoW/pN7jjA== X-MS-Office365-Filtering-Correlation-Id: 7827a4a9-20df-4763-3ff9-08d40eea82ac X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR03MB2472; X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2472; 25:GYC0fwJUzSBEGOfGJnGFsBuY7lxIQuT2XG4PLfpQsWHhfnC6kt3O+8Ex+DbBBxYaZe6IBm9+brZLcXMJYvAaFe8s6psPX0uLyTtXeGqV6GxiXr+JS6x0eY6StpNMR0SFmBVlhf1nwUEQeUr3z6xg8SUEgdeyIh5a4GSV+0tdu3UziocPaCGwjdQF1okI10QeykVYONqxbn/aAMHNTnbJJt/2AY/+p7PvMrtoszY0tcOtL8TtbcEPu0nmgoJUVlsafeElELoIMw+WoFreF6otx/irjYAkrs6K05gGJWFmCnsyX5XiztBZWNxePcFXaJkHNPUqLF6Y2LVBAPL9bNbofc1q24kTVfUlINJifVEd1wmFfWrDzaA8p+02pYVwH/8Vw1GjhDINMnhmtJIpQOgmGVO52q1kxXw5zuzO6PgoQdHL3A80dfeUogQeSuiUeaIVRQfBeHdJR3LG362IAnf+UuK8VD3/DodR30w9rRc6lweTyslQRtA0PJ0AgxMS4xxuvUyL+EggkR17ZGbDfWcY04p4PfCNHL8j5bo9ugCTNSlFQg83I9nqmJ1vN7l+7N926L4Imcov9l088ySuk7Zsdipq7RvxxKOUWGH//SzfA8S1mma3U942nQHEhKkG0lBJvXhooKv0sTvrsV1FAhqns5X77Vi3yVCjt8HcjqE9mWJry+Ds7cYZsZNGxhh+97Yv/AWAVPKjcCbRJ79ZTiVJNMWbK8DKLrbRV3/ftmkvFHQklxdg0PHLjl97rUl+Y1y09E35nWpK/9o4iBGrNhuNsepSInyk6sWuOKEza4W4u5YQvtJW32SGtmms71KlFVDmLOXes/ybaetTEz9TCkRK4tFhGFhCIO4X1zM9irOYr3UR4KJBmYrSgJej9tLNvaKY X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2472; 31:h5iX0H5bAoMMPpctYXXpGiRR5iK7pA3yvPb5OPMcYqC2Va/O47AVi8250rryqwwF9P3h6n2YQZyGdw9+7e8gwsbkz46NQsYcH+IlIvFBbCBvKw5mgmz6lRbqf7zljl6CWd1QoVGA6f+XXYht98hxJWS8e0xXKSZRRSnjqNP+KYwU8Lkyk2VYECenyP+FnY2fEWhdIRPVcnwhuXW+YJGGR0lUvOQTnA+fQ/ma2flBRz3LZ3gd/kLg9DZCpE/zEJF7qUqQmlgchHhZiyZyHg0cz0NqnLzmSKcnG79RlGplNf4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(185117386973197)(21532816269658); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095035)(601004)(2401047)(13023025)(13015025)(13024025)(5005006)(13018025)(8121501046)(13017025)(3002001)(10201501046)(6055026)(6096035); SRVR:CY4PR03MB2472; BCL:0; PCL:0; RULEID:(400006); SRVR:CY4PR03MB2472; X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2472; 4:+HvGLNbEGJ3yqBIomM1SSTkDJUYl2shQq8CYiIfkjwUuUfFdpdBt91lySMWD+2ADSZJkLM+7Hmmx+BxDZCBrNSSWoCa178fr8HlH42ysYPXd1GIWgKKruBtQZhCWZ3o2tZT9GJWYmrwQ6/hGx8NaE++UNW+kNwOHy9TrkuyBwLh4Nt+6FC2SidgEI3EPl6GRmp3Z9gTiZVXH3Bp2Q0IfqBZGN4brfnOqyPnQtOKc0eUuv65B5eZRJw/ueK1dAUEoPRH92AuDdBDA2J78SxTUrfZmOuaWzpLpM9znEFYq7PZgpp0UBtPPEXRfw/JwZtFGh6HogFtBt+WKQtoABDjfjUd2R5C479cwbxkULRFWhw4kmr4U0ZLPE8/h4CLcK+ORs7XnEzGWSaoXgTiC1gkK2pn06Oz0/qHDNeY1bL9UoIE3ZH5vrF509RtvdFI49ObOyG7IVBqYf07GjtlDfa1j6hqgFkcwPVpr2LK71YGMGhZbvTUrHVoIx+azJhL83ngVguqYc46Lmq7DpxqHdYHpwOSsuewA0tE4BpvJ3I6t78IkDQGshutLESPoA5d/hKaiBKrSzlgfd/aCC1X7mCkvvvYfg3140qEa2ugDBvtlrPKPVzrOtrTv14FboT9RNeCgvANieVBEqXUG8YHoRqVUHw== X-Forefront-PRVS: 01294F875B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjAzTUIyNDcyOzIzOmdPVnJrK0pwRUZvZzJXUGVWR0ZKV09MajNl?= =?utf-8?B?LzR3dnRhbVA3L0FUc0F0U1djUXRtT1pBS2Q5dVJSZEV6R2J2akY5MzIza3pn?= =?utf-8?B?YzZ4dXZwWVJZcHNlcGNSMVJ2VzNFSXA4MStCcFBTajQ1ZmkrZU5rbU1KZ1lo?= =?utf-8?B?WCtFK01LZitrcldxbUV6MU1ueDdHUmxEY1Zuei9ubGNrRTR1em13T1lZVWpv?= =?utf-8?B?ZXgyTnF0b3hVYyt1TmkrdzFEdU9wUjVGMG5FNktvNnBkcC8yVzVOZU9jSEtD?= =?utf-8?B?bElOMVNlSXVpSm5WM0pxYjNTOHZPYXF4QUMzZ081SytXSEN6cHdCN1cyVTJh?= =?utf-8?B?Q1pwdFNzTnlZUkI0VVpMVzF4eFpSYllWS2R3TGthNFpnb2doeXhXUjlleDRa?= =?utf-8?B?TlVnRDR2ZE9GdXdnaHpPSU5NWUUza0tQdmozbFhTT2hOaXN6TDV6bytSNVN4?= =?utf-8?B?TG5FaTdwdUwvMW9FZzdQa2VoTnB6b3hQSktsZDlDZlp3akNINjNKYXZtOXhW?= =?utf-8?B?YldXUzNmV2toYWdZQmhwaGhGYlpIYXVTdUJOdmV2V1JVbnpYQmJuMHBOekRn?= =?utf-8?B?YUJFK05GMWo2N3ZGVnVhOEFiRjRjdEpKQmU0L3NtSVArVHRBTUJYaWt3WkFK?= =?utf-8?B?MmFzelFCVzRVNDhrZ05kWDQ5Q01ETHlKYmYrOUM0ZG5aNUlmL1g3ZDdhdTVG?= =?utf-8?B?M2cxNTZPMWVlMzB1dzJKcnp6b3g5RXppRWQ5RWp6WllXbzZNbzNiNWxlVDFz?= =?utf-8?B?ajVRZDQ4ZnQ5T1A1djcyMGZoeG1jNU1NUkRReHNZMGphRHBSRit4ZmFJS092?= =?utf-8?B?QUVMRE9UT1NCNXhoWTlMRmRRa1BhSGlrVzAvMy9BZzVYQ3NWTTNRUEtnZHRh?= =?utf-8?B?bEZlRzQzZWlZRndmRFZEKzdlYUZ3dy9oYm12NTNXenNYYXVQTXUxeW45YXlx?= =?utf-8?B?Yzd3VThsdlRZckhxUVM0RHhHL0k3UTBrOXVSM2RYWUJ6QTBnOTMraHNmNXRK?= =?utf-8?B?L2VRSUcxN2t4VWp2bU9zNHhaa3Y3UzBLblRYZGhjcU9GdVpkb1d4TTBNajln?= =?utf-8?B?dkROMnFGVVFYQlN1S3ovUEExbG1OVzNyWjVIOXc2QVdaZFN6Vi90SDQ4dTQw?= =?utf-8?B?ejBCVzFsbHFKTm04bStUZ0RYWXN5ZnVaU2tUbXZkSmlTMFFRMlpWSThSM2Np?= =?utf-8?B?ZEFMWEhFVEZ5MUdqM3hrRDZJTTV6MExlR2ZadVdjc08wNUk2UnV5Y0Z3T1pR?= =?utf-8?B?aWROOVFOenEyRkVjejBuMEUvZERvcnJ3SUVacFIvQnBBUHdSYXp0Vk9xaWVv?= =?utf-8?B?Z0ZPRlZQTGwxSEVwd3N6YzRiT3RSZ2ZaeklrUWgrOVdMbURaMjlVR0NnYTNa?= =?utf-8?B?SmJMTWk2dk1sU0lhZ1JYWGVEd1NlK2RmY3hmY1JTRVp4M3owVDAwSlFhMy8v?= =?utf-8?B?TUtTSlpVZ0xJTmI5eDdlMG1TREFpamlMRUZsTVZxdEVEY2lVN3lSRnRNKzNG?= =?utf-8?B?aGg5dlQ3WmxEUGpjbVYxYnJZcE5qcFF6S2J1eG5paG4wVUVJOHZBYm1zYTE2?= =?utf-8?B?azN3YkJWQkhwT1FYTkJ4NnZmQ0U3SVYyc2c2YXhESGdJNG5zUjZoTStQUlE1?= =?utf-8?B?eUpzV1YrVFhVK0Foczk5VjNPWVQzTXhITys5MEZpREo3NFFHUWQvWmxCSHla?= =?utf-8?B?YXY2enk4cERUWjNyMllLbG1TOGM0Z2gzOXZIRWpMeHZPY2taM0t6dUhLL0JR?= =?utf-8?B?ZGJZUm9xWXRTUk1kdkt3UG9uUU85ZjR0VllRcVpUMWxZZFZ6WW93RjNzLytP?= =?utf-8?B?NHBQU3o2aFRyeFM1d3hNc0U3TkEzeHhTMDZwMVVydWhhSEE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2472; 6:BCKOERjViAZZ9FRsQjkG2g//yfqNp1at1x9jU0wD/VOPOW8caZYlPvD8jNtQuanCUDi9t63xz35eLFmsG9rduKedmj1QW5DbY4QSnJWwsqtaZKpGUakD2x6Fs1dNN/aHNRsMe7/lBWmqFtcmzWJbq26X8DEqXRPPijbjHu5zJK6S1BgXLnRItaU6BjP9b+kzzM9hmrJLI7tBMZ8eHVLFzg/t4TZ/VxzhgjLwi3FJ1pymUf4skArlzCBHglNoVDxzwoo7tExuyUPUcgkBC721MjnQTRjAhgQCiLtFcg3D2vkWcoI4aXdMdj6CZxIdIRH7OWeBNMkB6+wW42h838pU2Q==; 5:MT18aQgJIseizuaZiV5EQeXm35E6CpCtZSBEz+y/nhOFULLTd92FEP5DqyH74BlEizrz2TSPRt7iJRi5JAAm8VGLay7dCQ4obLLhb8uQ/rOYyuRSwFDrLMv24HhwxkxlX+OSTh4ECTphB74yoymTQ3OF3oFuo/Oi7Lo7PKLPEKt+99Nto3toOYWF4pWOp/9+; 24:6qzWSYw24ycbnp31yGVqnEUFiN+4M4wFK3AEhQKZBLcRt/4IQh43yLDv0hUMp/PcXImb+THnDoBEMum+cnoOE+OLz23oPv0qamEfML/rxz8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2472; 7:grrfKwdHzPYCOgFr4VzgAW76eC2CtxL+Jz/MNnR1P+R6kb0BcfPi/WBmvQn5SRuQr+sYl6UZV48eUf51fhNXFv0zp73zt+a0B2KhWMN6Fh8RKbsRgUP8cPJ+j62tq4vjhsyGpulDbg6qTrn5kzzHf1t5UnN15KtRP59DTOlnsQrhShcc+4KSgIvh7ETj2Vn97w6e2O6MCL/63F0NIlFpq8uKud4AcXEFPis3BPG5ClMREhSz7Mfqv03i6U8jiup8KzlZwVyVy4zJxBpPFmqeJsmuUqRsLwBdRFen4Eb0BPAYpAq4q8uvt5Fv+j4915wgeD1sQ8IEg9VQVBPr6eEbqTYDBCWObBp4QtEunlQFs/w= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2016 13:06:14.1829 (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: CY4PR03MB2472 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: Thu, 17 Nov 2016 13:06:17 -0000 On Thursday 17 November 2016 05:25 PM, Jan Blunck 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. >> >> === Patch description: === >> >> Patch 0001: Introduce container_of macro. Originally a patch from Jan. >> >> Patch 0002: introduce changes to rte_device/rte_driver for rte_bus, and >> rte_bus definition itself. >> >> Patch 0003: Add a new layer for 'bus driver' with linuxapp PCI as an example >> >> Patch 0004: Changes with respect to rte_bus APIs and impact on eal_common_pci > > From my point of view it is beneficial to keep the PCI support in one > place. Moving the match() and scan() > to the drivers directory doesn't seem to be technically required but > it makes the code harder to read and understand. It is not a technical requirement - just logical placement. These are bus specific logic and should exist with the bus driver - where ever that is placed. Though, I am not entirely sure about 'harder to read'. If a person is reading through PCI's bus implementation, I am assuming it would be nice to have all the hooks (or default hooks) at same place. Isn't it? Or, maybe you are suggesting move all librte_eal/*/*pci* out to some common location. If so, that is something I haven't yet given serious thought. > > >> Patch 0005: Change to rte_eal_init (of linuxapp only, for now) for supporting >> bus->scan. Probe is still being done old way, but in a new wrapper >> >> Patch 0006: eth_driver removal and corresponding changes in ixgbe_ethdev, as >> an example. Includes changes to rte_ethdev to remove most possible >> PCI references. But, work still remains. > > Making rte_ethdev independent from PCI device is not directly related > to the rest of the patches that add bus support. I think it makes > sense to handle this separately because of the impact of refactoring > rte_ethdev. Once rte_device is available, the change is independent. Only dependency on it was changes required to rte_ethdev.c file because of various PCI naming/variables/functions. And that is indeed a very large change - including changes to drivers/* which I haven't yet done. Are you suggesting breaking out of this series? If so, can be done but only when formal patches start coming out. > > >> >> === Pending Items/Questions: === >> >> - Interrupt and notification handling. How to allow drivers to be notified >> of presence/plugging of a device. >> - Placement of bus driver/handling code. librte_bus, bus/, drivers/bus? >> -- Also from a pespective of a external library and whether symbols would be >> available in that. >> -- and secondary processes >> - VDEV bus is missing from current set. >> - Locking of list for supporting hotplugging. Or, at the least safe add/ >> remove >> - PMDINFOGEN support or lack of it. >> - Is there ever a case where rte_eth_dev needs to be resolved from >> rte_pci_device? I couldn't find any such use and neither a use-case for it. >> - There should be a way for Bus APIs to return a generic list handle so that >> EAL doesn't need to bother about bus->driver_list like dereferencing. This >> is untidy as well as less portable (in terms of code movement, not arch). >> - Are more helper hooks required for a bus? >> -- I can think of scan, match, dump, find, plug (device), unplug (device), >> associate (driver), disassociate (driver). But, most of the work is >> already being done by lower instances (rte_device/driver etc). >> >> Further: >> - In next few days I will make all necessary changes on the lines mentioned >> in the patches. This would include changing the drivers/* and librte_eal/* >> - As an when review comments float in and agreement reached, I will keep >> changing the model >> - There are grey areas like interrupt, notification, locking of bus/list >> which require more discussion. I will try and post a rfc for those as well >> or if someone can help me on those - great > > As already hinted on IRC I'm taking a look at the interrupt usage of ethdev. Great. Thank you. Do let me know feedback for any changes that you might require along the way. > >> - Change would include PCI bus and VDEV bus handling. A new bus (NXP's FSLMC) >> would also be layered over this series to verify the model of 'bus >> registration'. This is also part of 17.02 roadmap. >> >> [1] http://dpdk.org/ml/archives/dev/2016-November/050186.html >> >> Jan Viktorin (1): >> eal: define container macro >> >> Shreyansh Jain (5): >> eal: introduce bus-device-driver structure >> bus: add bus driver layer >> eal/common: handle bus abstraction for device/driver objects >> eal: supporting bus model in init process >> eal: removing eth_driver >> >> bus/Makefile | 36 +++ >> bus/pci/Makefile | 37 +++ >> bus/pci/linuxapp/pci_bus.c | 418 +++++++++++++++++++++++++++++ >> bus/pci/linuxapp/pci_bus.h | 55 ++++ >> drivers/net/ixgbe/ixgbe_ethdev.c | 49 ++-- >> lib/librte_eal/common/eal_common_bus.c | 188 +++++++++++++ >> lib/librte_eal/common/eal_common_dev.c | 31 ++- >> lib/librte_eal/common/eal_common_pci.c | 226 +++++++++------- >> lib/librte_eal/common/include/rte_bus.h | 243 +++++++++++++++++ >> lib/librte_eal/common/include/rte_common.h | 18 ++ >> lib/librte_eal/common/include/rte_dev.h | 36 +-- >> lib/librte_eal/common/include/rte_pci.h | 11 +- >> lib/librte_eal/linuxapp/eal/Makefile | 1 + >> lib/librte_eal/linuxapp/eal/eal.c | 51 +++- >> lib/librte_eal/linuxapp/eal/eal_pci.c | 298 -------------------- >> lib/librte_ether/rte_ethdev.c | 36 ++- >> lib/librte_ether/rte_ethdev.h | 6 +- >> 17 files changed, 1262 insertions(+), 478 deletions(-) >> create mode 100644 bus/Makefile >> create mode 100644 bus/pci/Makefile >> create mode 100644 bus/pci/linuxapp/pci_bus.c >> create mode 100644 bus/pci/linuxapp/pci_bus.h >> create mode 100644 lib/librte_eal/common/eal_common_bus.c >> create mode 100644 lib/librte_eal/common/include/rte_bus.h >> >> -- >> 2.7.4 >> > - Shreyansh