From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <shreyansh.jain@nxp.com>
Received: from NAM01-BY2-obe.outbound.protection.outlook.com
(mail-by2nam01on0079.outbound.protection.outlook.com [104.47.34.79])
by dpdk.org (Postfix) with ESMTP id 1D651282
for <dev@dpdk.org>; Tue, 13 Dec 2016 07:53:33 +0100 (CET)
Received: from BN6PR03CA0044.namprd03.prod.outlook.com (10.175.124.30) by
DM5PR03MB2476.namprd03.prod.outlook.com (10.168.233.22) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
15.1.771.8; Tue, 13 Dec 2016 06:53:32 +0000
Received: from BY2FFO11FD021.protection.gbl (2a01:111:f400:7c0c::179) by
BN6PR03CA0044.outlook.office365.com (2603:10b6:404:10c::30) with Microsoft
SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8 via Frontend
Transport; Tue, 13 Dec 2016 06:53:32 +0000
Authentication-Results: spf=fail (sender IP is 192.88.168.50)
smtp.mailfrom=nxp.com; linaro.org; dkim=none (message not signed)
header.d=none;linaro.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
BY2FFO11FD021.mail.protection.outlook.com (10.1.15.210) with Microsoft SMTP
Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.761.6
via Frontend Transport; Tue, 13 Dec 2016 06:53:31 +0000
X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:;
SizeAsReceived:1259; 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 uBD6rRGr001018;
Mon, 12 Dec 2016 23:53:28 -0700
To: Jianbo Liu <jianbo.liu@linaro.org>
References: <1480846288-2517-1-git-send-email-shreyansh.jain@nxp.com>
<CALwxeUtqnNpm=KuR3Qtb2PNUghAc=e9TKQqm4Uh8pvgZ4EmriA@mail.gmail.com>
<fd35ef7d-77a4-c79b-7d6f-a14a2a5a56ca@nxp.com>
<CALwxeUvOuu+kMjdB3-KZJ=hkRjs04ywhxvURqJ441-f0FKe83Q@mail.gmail.com>
<1697fe66-962d-0848-5e68-615249b52dad@nxp.com>
<CAP4Qi38CYGC612kQJpA49xWRF=jpqJ1COWg=Qe18HDzmiLVSuA@mail.gmail.com>
CC: David Marchand <david.marchand@6wind.com>, "dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas.monjalon@6wind.com>, Ferruh Yigit
<ferruh.yigit@intel.com>
From: Shreyansh Jain <shreyansh.jain@nxp.com>
Message-ID: <768defac-1538-e425-7f78-0d88d3303d06@nxp.com>
Date: Tue, 13 Dec 2016 12:26:14 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAP4Qi38CYGC612kQJpA49xWRF=jpqJ1COWg=Qe18HDzmiLVSuA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-IncomingHeaderCount: 13
X-EOPAttributedMessage: 0
X-Matching-Connectors: 131260856115774482;
(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)(336005)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(39380400002)(2980300002)(1109001)(1110001)(339900001)(189002)(24454002)(199003)(377454003)(4326007)(2906002)(50466002)(93886004)(86362001)(31696002)(36756003)(31686004)(230783001)(105606002)(230700001)(15395725005)(76176999)(54356999)(50986999)(92566002)(83506001)(626004)(85426001)(106466001)(97736004)(5660300001)(38730400001)(4001350100001)(47776003)(77096006)(6666003)(104016004)(65826007)(65956001)(110136003)(6916009)(2950100002)(65806001)(189998001)(356003)(64126003)(5890100001)(229853002)(33646002)(8676002)(68736007)(23676002)(81156014)(8936002)(81166006)(305945005)(21314002);
DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR03MB2476; H:tx30smr01.am.freescale.net;
FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD021;
1:PWZAbjPq8Ok1POAZ4WWOJnqMlDIvUzjcOmdvbg/80Syjj2V07HqD+kSWLHGVv3yfw+pnqB6g/72RPElxEisdv35UGUI+8ZXjqEv7e3pGkXnY6jJhziXXApjfO3dvZn27qa6hXvYtZe++Bt+IV/IRFize2Wx+aS6atBKh9ZKt2YekqFuha0zGSc3ojUhDmyG6EgILyzElI1/fEE5QRJZ5QorsIFWZx8HP9nXHqO30p8vMwRw/I35QPJWpYeW82Q0lBoLF0gx6GgrYngB6b2BOWDeZrK4MDHQFvD76MUxbo+SeOLd+eqX2PmI+ox7AD9oSwlo1RjkQ2aVDJdaEd/lC3Kbt/YhPRaVckGdfUiZa3ZY8Lsxr0kS43oeEFrejKLTlN+WtOIBWB646V3eW+oIgv18L86isUU9WnVELMZuYRFd6L6o8qFpTQyd2ucLYnzv819BzGPpB66kCA/DMa9pGB+GFUoczbbiJyq9Yif/LwNw9dT2TrTUJ1o6eknbUfZKVymG/Sza0X8lZbrWGRUmlP2s9FGgI/LcenpePWP6blod8XTggx87tIwdhceojMgvjI+FKM6EKJPzF7AJIo4+/ERXfZPc1ABnyPGWLzK3AmBFjIBVv1pTxuMPgMDMik9T0AGu3ZaW2yBafATyUYOlO0g==
X-MS-Office365-Filtering-Correlation-Id: d4562127-10a4-4abe-b912-08d42324c015
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR03MB2476;
X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476;
3:4B+8hS2Tix5/cfeyjq1c43FFdJnU7uRVJztSDpOAFyOAYaCJEoyH7GfBoBWmACj8MiF1vRUZXerqgU8Ur7rXZyVa4kdhI10acixoa7j7pBu5YrQs/67KYNAoZycLb3ciUM8OPtYr7cRrR4Ysl8O1r4E1WSS2xqMFlwIRlvtk8heW6bYK/i/9HZg0ldj4vChpluKs4uv3p8RM66X1ViHmSpRJv6CCci3YwmDSORdL7tKk5ZAzYc8aXFB3WfKpqTmIbA/E1Gd6xpiU230c8/Q2Q9HbmrAR8Eoe4S0JomMGtXTJKD21s+Vjjb4oT767v3vKm3sskx8k4QKlgSG1LYKT4mzITeXa++kSR92y08lftJ2wtkPlzwvJ9h9V8Hg4llUX;
25:hpWkPUOkBWsoWKKWPgH31TfJbEyD9H3lpa8sqm7su73RSiscguO6YNVIuhURy9QtXp6TbGfEeffGCy7Fn4PxAOFUIc58tsNiWGut4ZBy1lIrZ7S7E1wbJRMM7ylNunghUv9LFkoNady6yegMXOOlL9vK5sGCIw7yewZrmWHZyOc5x4flNyg54Bi2dNbeQIzbAILtRh8wO+Dx2rNqtIwYn/HZR7CLFUR4Fn27T0+pZuhJqyHkC1OdhY/eEZC8XTDKeJU1QWchosJ5C+rfYpHgaEdxCdcNBlceenl5q8+1kgYHxlZ8CYlyjQhCr3LzSqV2e6x2ASB4a8b4RyJEQq3mFKm8wx1e43FXTzD8Ohr8n8FizDT/Le1Zfm2b/VNbLSgmJJwsNo7GUSUplzDsutqR4I7uAib/xX6oWESKYj8+6kqZ2UkGcdiKQV1tAPdKny0/V83VZffMBwCvEciGHSdTQA==
X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476;
31:foeH1IIDP7gT9MmQGzDwkNjGLJfcuFLSTzL8p/6m6ZhlLQHUYL89/kV4XYjQcvuvIEYNyCwncH5caaOQi/5mvXuUgZLFyxxFdyAdvAhQvpmBYxY+wKN6tCnbeNfbJkxusEOOrfeKaHoRV00VtYOBkykZ14yEnsoxO2mP0Z5XzD43z3iV1A3CE9fGZn5JoOqlq+JnX7nQDeiZrJ/xGkh5jEos7cMfzeFaaZSIQl2tn++Ocw5+jfobXTWXAiGlXvXzdbGUZnO57PjRFhaY8USqClQ6esC0nhCSEivZbi8zyh4=
X-Microsoft-Antispam-PRVS: <DM5PR03MB2476ABAC8AFD5F3E07A43797909B0@DM5PR03MB2476.namprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(185117386973197);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0;
RULEID:(6095060)(601004)(2401047)(13017025)(13018025)(13015025)(13024025)(13023025)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6096035)(20161123565025)(20161123561025)(20161123559025)(20161123556025)(20161123563025);
SRVR:DM5PR03MB2476; BCL:0; PCL:0; RULEID:(400006); SRVR:DM5PR03MB2476;
X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476;
4:yon6lu90wWap6TsdKcjiHftmb5pRsim9yBi8fMgeAtcnDyy24QiE8xpQhY27tfthBteZWCU/JiuAyIFOjxJdtGoTDG/MW4H6j59SAPGiaarXW9vDpf2FEc1OLvo1LH9PHpWYqcgtCT1DahZEvMI+xp0KhjNSJPQnUYaQpXUI6d2tLWyNPjrCF+hS/6lc2z0eIqAJVLt8x5hYGb/C7K8eT84dk+nQI9GsbxCIIA77n1urarJ+YmzaZrLunUSDQwEeIdSJoD3MWPxpMaqkriGl5hLc3EFnzM4jViOiRlemkh+O8YLoinonVfrylVotxa9ujfdV3kGW0QgN23wnYqZWTLTGcQgzVLhJTd2vX23p2LjnC31AUgDauVpLah72JAJ1PP1GTLaC9Fu1LgvLmkGGxn8HN0u4yJeFhslMOfqLjOkEQXt361jYNaE0BNq1C6Y5mfR4GOmHwcH5VXaVi+nhzS3OXwoLY+KA9CgIug10gy485Te4MWLRdiyM/OzgqNhEbAhKkluWJedcnzdgofdy5MrSvfBKSg4PwrAP8CW+IC4A+FyiCdJKufKNmaZ2d30+eFpZhsD1zw42F5YOlVaTA532/rgNN80wze4G+zolbRE9YoFN8BsAnmu0u0qUPZwddQAZ+8QtkK3O3xuZlyQXlpzdnQ8gRInL5NxDKkrixTuDPxLbgWa3895F7UWKsmUPJs129b2WCFyJ7pU9FdEQaClEOMPBUKmeQMS3D7THLryad91tVl/Ej8X9ac/N/nqN
X-Forefront-PRVS: 01559F388D
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjAzTUIyNDc2OzIzOmpER0VRSnJQdDY4RkN5MTdjZi85VEV0Tmh5?=
=?utf-8?B?VlhwWjRDYXF4SEIvemdjR2RURnZDUkVLNzBONm1LZTRNVXF3U3JwTUFYckFj?=
=?utf-8?B?eTVYNE1lazFQT0lUQXZTNHM5YVRvZU82VXBlc2dQdnFINjBZbVhCdFUzUjgy?=
=?utf-8?B?Z3hTb25iWk9HYitJSVJDOC9HYmpxWFNTOUkwQlhhbE90Y0lGeTEveHlla1Ay?=
=?utf-8?B?blEzdXFlSUVHbVBaSzhhY014QVU4V0xJaXg4MldsSmtWYldXaEtzdHl6RkxT?=
=?utf-8?B?NERmajhUbU1PbE1aZWxIdE9YOHlrL2RYSkd3S0txcXFjam14d01IbzdPSjRB?=
=?utf-8?B?bThaSWF1SjBRZmxBZmxoNW5TaUFwcmZNWHQ0T0trb2toWTVGOVp4amo4L0JO?=
=?utf-8?B?UHU3VEplU2VCbXlHUThYejlMRXJBU1FPVGkyYjJCdDJQNVhZOWNvTjlocXcz?=
=?utf-8?B?cW5Pb2RLS0cyR29uY0RCakp0RkVLVTF0RGRiY25HM0lqZTZtOFBnSVgzZG9w?=
=?utf-8?B?a1BVTlpjdXUxRHBFUWJRTEljS0tqck5HWnJSN1BxeUo4eHBVODFndlhSU1d2?=
=?utf-8?B?THlYdGJ3aDJCQTkzV0lDZlFQWHF6RlVISDFTVW5DOWRmazVkbnowV1MvTkRi?=
=?utf-8?B?cEhKZHdPZDJyS0xvSzFRZnBzZHZ0R0dLbi9qbk9ZREczUnVCeXFBZ29LbThX?=
=?utf-8?B?M0Jvd29XQ21oWUZCWDE3LzRjNWtwTno3VjdWYThlcTBZM1VlTjBWK1JWdGNV?=
=?utf-8?B?NlVxa1MydDFlbjFqbXJqU2tJNXRHbFFMcXluZC9MVVJubDVXdjNtb1dJK01O?=
=?utf-8?B?bnBiK3BESmZmZE01ZEl5dG42WHg0dWN6YkhrdWcwZGVGcXJabnVKVGROR3dw?=
=?utf-8?B?Vi9oU2R1VURQdG9xcVY3bnFyenFtc3ZSa0lrQmdIbzYyZ1FoTjhHU0dDL0c3?=
=?utf-8?B?bHp4VDlSMDN0TFRvQUZqNUd3R1o1Qkg0RlNRVjlCM281cVhuN01VclRXaHBO?=
=?utf-8?B?bGdYYjFqaTBZdkYzb1R1VFZFZ0JzWUpDeXQ4UXlKcWRXZVQ0TmtQSXRyblYy?=
=?utf-8?B?SGhBWXIxMzdJekVreStBNlNoT2I0NGc2ekhnZCszdmFONlB6ekdpanQ1M0Ew?=
=?utf-8?B?d0piN3NYUGJvUlZraHRVK1YwTm9lVlhycmsybWZaMjVlSUVVN240QlFPUklM?=
=?utf-8?B?WUJTaS9Palg2bDlUUDAxZ0FtR2Ztc3hpZDBhRWVXRmp2ekIwNlhVZm5aUldm?=
=?utf-8?B?aDMwdHhhMEJab0psVmpERmZvL3BRakJESjljY2sxK1JEbTNkbjlHSlVORjE5?=
=?utf-8?B?RUtSczFYTTdxNzZjcm5FbHJiRStoOE5JTlNOeUMrSmcxVzg1TSszdHQxNXlp?=
=?utf-8?B?cTRzaHZTQ1k3KytKVXRVTHZ4a28rNEo5R0xHN2ZXSklneHdwN091SUJ6SVM5?=
=?utf-8?B?NTR0SW9kanVmdFRPS25FQ0tFSHM0b2JDaVB0dE9vTHRjTzdhSzVSSS9mZ1VU?=
=?utf-8?B?SGpKa0x3cFlCazhwOHBQa3FYVDJ3bGhaWnlDVGk5UjhSN3lHZ2pSSVUvY0xX?=
=?utf-8?B?K2ZkM1V2RVZONmZ0bTJLdkFscWxGZEx5RU5oTlphRWhrU3BVZHlidjN4OTBE?=
=?utf-8?B?VlpaSUJrdFFJNFdjVUVVVWZncVJtR1JxWFM4NElyd24yR0VLMFU4YTBwclVW?=
=?utf-8?B?ZmlJeUVmVFhsN2pJVFZUdEpiS0ZMbWpza01qaU9Jc0NsaGU0WlNMeVNHbHI4?=
=?utf-8?B?L2pwTEdHMGhUSEE4c25iUDl0cVFCK2txVGxKL1JQUGUzOE1BMmdCd1FTNTh0?=
=?utf-8?B?cUhtVTFtWVo5dWd0Y0VxN1VJdWpQTFZRQlBRc0ducDhmcjBBalc0Q1k3bGFr?=
=?utf-8?B?YVZtMVJ2QmR5ckhnUGhHWkNTK3A2WXAyRlFCczFvSjh3YndxSkZUODVSK3Fj?=
=?utf-8?B?NUdrVUo3ZlhXL0gxbWxmdEVsREptRWpTeEdUZDJuWk5JdGVJN2luV205T01K?=
=?utf-8?B?RzFRTm5pS2JPRWN6Ty9jekJjWEhwenQzQVJPQXRyQ3FxWWY3Vmc1WS9iN05o?=
=?utf-8?B?WTJyaWxRRW9tMDJOVzltRWY4MFpTMDh2TDZibXpwWUZmQTQ1REFyNFFCT2cy?=
=?utf-8?Q?cMD6AbU/+QRds4An6Hw62d77DhTEzJuIRLN2Gm9CcOv0?=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476;
6:6jrlbIYHqFx/GvMQJthGbYz+bOcAVtIfrT6CiPqUg5rXeGAUIDKeCeIwxPr+fZiyVwSUDuuyLiwkveywujuBQm7iqhO2Ak94HP3yXZEtAk/1+vMgSLLbFdcsI8Vrx2kPObkcNrHaX1u+6u3FdtXgRjFifigztaqBQtsakbZiO9BAFIL9AfVKPpEWr39PA6psmXvKq6jGEwJtw7/KAzKq8Z/dGneWD3bf3HfbWF5+dlcom54RulhgWJDyhxi1/e9sWcjxsPaQODCXEHaISJSjlLm1lGcEXbC+WBgnCn3B/PHqVFd6BHmru/+i3EIjg66KNvh9iJNtHOFR1j54FP7nHpG4PLE0QFAix8DY3PwgCv2T4Kg3qnB+6nPhwhXjiFPZjkZqXuVE/1KaRyGK8OiDqOxIKhwQwK3UM16sLMRN0UVmKr27EreKJbjKCW2K3vh8;
5:2cYtWThP0/NX+VLRqgxgOKPpzgG9HUiEQuRY0iad8LZXOTflrway4hBb1Giy9ty+MFmB0hJoVH1Bt/nio3kiHkoVVEpc68LPTSc+dUyO8tT9V2R7TnMF/F65yUI24W5cVHDHiiKaT4ypYrscZkPHo1a5aaaNaZcquyaxoU7LZ3Ab7cqKTlVoH/idD5xlqcir;
24:/0whccjmiQBI4UeYb/ShEHZbRPNAm5ppTzEWOCNdN6/TYVNwf7hL4YwhmFc2aPUCTlCQYbCF0EYRfhojGvY1yF+/jlRwdAR97HBaEiYxTt8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476;
7:kk09E3N/y3VepYI/f7FRcVBntD8Gwq1v0MZM/y2h3ehglq/r5CgTfNfvOLiHpzAbgJtWGzztS6wz8pBRiHChrX5Yt56mBX+IEKqxlrhgd6P8Rb6bNDwR8qRFbVxrRs2sm6ORyCZoLkoeJc8c9ZJB16+pOcia7tYCZJHtdQgFJYmPwrXnoz62CLm4k52MCZG4iKUEalAOAy+FWMFnO4FNw10mJWGZujosCIk0We+hkRdnA/9h+2xdOp1PaL5o/jsNLJrTzqgiPcAgc3nQOlQ8MWt7a9Yw1mABWStjwGHng4yLP6E9yUewgZ0cZw4T4m7ITkidB3QyLAvpEGCklLQccjUALnvOdU6glfPx2FSleUPxpfL4xK3HlaTuark3ah0JPFNVLep2Kys0rlaQ0w3jxaODXZfpUzgrU+DiUSlvZxx39bbYYv3S0kkAi/SeZsM5FgtWsT0r0pm/U6tSJDmGpQ==
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2016 06:53:31.1718 (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: DM5PR03MB2476
Subject: Re: [dpdk-dev] [PATCH 00/13] Introducing EAL Bus-Device-Driver Model
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2016 06:53:34 -0000
Hello Jianbo,
On Monday 12 December 2016 08:05 PM, Jianbo Liu wrote:
> Hi Shreyansh,
>
> On 7 December 2016 at 21:10, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> On Wednesday 07 December 2016 05:47 PM, David Marchand wrote:
>>>
>>> Hello Shreyansh,
>>>
>>> On Wed, Dec 7, 2016 at 10:55 AM, Shreyansh Jain <shreyansh.jain@nxp.com>
>>> wrote:
>>>>
>>>> On Wednesday 07 December 2016 02:22 AM, David Marchand wrote:
>>>>>>
>>>>>> 0002~0003: Introducing the basic Bus model and associated test case
>>>>>> 0005: Support insertion of device rather than addition to tail
>>>>>
>>>>>
>>>>>
>>>>> Patch 2 and 5 could be squashed.
>>>>
>>>>
>>>>
>>>> I deliberately kept them separate. I intent to extend the Patch 5 for
>>>> hotplugging. But, if I don't end up adding support for that in this
>>>> series,
>>>> I will merge these two.
>>>
>>>
>>> Fine.
>>>
>>>
>>>>> The constructor priority stuff seems unneeded as long as we use
>>>>> explicit reference to a global (or local, did not check) bus symbol
>>>>> rather than a runtime lookup.
>>>>
>>>>
>>>>
>>>> I didn't understand your point here.
>>>> IMO, constructor priority (or some other way to handle this) is
>>>> important. I
>>>> faced this issue while verifying it at my end when the drivers were
>>>> getting
>>>> registered before the bus.
>>>>
>>>> Can you elaborate more on '..use explicit reference to a global...'?
>>>
>>>
>>> The drivers register themselves to a bus using this bus specific api.
>>>
>>> For pci, this is rte_eal_pci_register().
>>> The pci_bus object must be moved to eal_common_pci.c (we can stil
>>> internally expose for bsd / linux specific implementations).
>>> Then, rte_eal_pci_register() can add the pci driver to the pci_bus
>>> drivers list even if this pci_bus object is not registered yet to the
>>> buses list.
>>
>>
>> So, in eal_common_bus.c
>>
>> --->8---
>>
>> struct rte_bus *global_ptr_to_pci_bus = NULL;
>>
>> struct rte_bus pci_bus = { ... };
>>
>> rte_eal_pci_register() {
>> if (global_ptr_to_pci_bus == NULL)
>> rte_eal_bus_register(&pci_bus)
>> else
>> // continue as if PCI bus is registered
>> }
>>
>> --->8---
>>
>> so, no RTE_REGISTER_BUS()?
>>
>> If yes, then RTE_REGISTER_BUS() should also check for an existing
>> registration for duplication.
>>
>> I was banking on a model where bus handlers (or bus drivers) are independent
>> entities, just like PMDs. So, we have a bus XYZ without any drivers
>> necessarily based on it.
>>
>> By making registration dependent on driver registration, it becomes implicit
>> that buses don't exist without drivers.
>> I am not in favor of this - or maybe I lack enough reason for this (about
>> how it will make framework/PMD life better).
>>
>>>
>>> And no constructor order issue ?
>>>
>>>
>>>>>
>>>>>
>>>>>> 0004: Add scan and match callbacks for the Bus and updated test
>>>>>> case
>>>>>
>>>>>
>>>>>
>>>>> Why do you push back the bus object in the 'scan' method ?
>>>>> This method is bus specific which means that the code "knows" the
>>>>> object registered with the callback.
>>>>
>>>>
>>>>
>>>> This 'knows' is the grey area for me.
>>>> The bus (for example, PCI) after scanning needs to call
>>>> rte_eal_bus_add_device() to link the device in bus's device_list.
>>>>
>>>> Two options:
>>>> 1. Have a global reference to "pci" bus (rte_bus) somewhere in eal_pci.c
>>>> 2. Call rte_eal_get_bus() every time someone needs the reference.
>>>> 3. C++ style, 'this->'.
>>>>
>>>> I have taken the 3rd path. It simplifies my code to not assume a handle
>>>> as
>>>> well as not allow for reference fetch calls every now and then.
>>>>
>>>> As a disadvantage: it means passing this as argument - and some cases
>>>> maintaining it as __rte_unused.
>>>>
>>>> Taking (1) or (2) is not advantageous than this approach.
>>>
>>>
>>> 1) is the simplest one.
>>>
>>> When you write a pci_scan method and embed it in you pci_bus object,
>>> but this pci_scan method still wonders which bus object it is supposed
>>> to work on, this is a bit like Schizophrenia ;-).
>>
>>
>> :)
>> This now is linked to the above issue of constructor priority and having a
>> global bus reference. I don't personally prefer it.
>> I will still give this a serious thought, though.
>>
>
> I'm also in favor of (3).
Thank you. I was almost done with v2 and in that I had changed to what
David had suggested. My preference too is (3). Now, I will prefer
sticking with it - until someone comes with technical issue (like
compiler compatibility etc) which I am unaware of.
@David: Can you re-think if you still prefer (1)? If so, I will change
it in v3 (I will send v2 in a day or two max).
>
>>>
>>>
>>>>> Is is that you want to have a single scan method used by multiple buses
>>>>> ?
>>>>
>>>>
>>>>
>>>> Yes, but only as a use case. For example, platform devices are of various
>>>> types - what if we have a south-bound bus over a platform bus. In which
>>>> case, a hierarchical bus layout is possible.
>>>> But, this is far-fetched idea for now.
>>>
>
> How to express the hierarchical bus layout as the bus in your design
> is more like independent objects to hold drivers and their devices?
What I had in mind was something on the lines of:
1) Add a new linked list 'bus_list' in rte_bus
2) OR, embed rte_device in rte_bus
(1) is for maintaining buses as independent entity; (2) is for treating
buses like devices (very similar to what Ferruh once suggested [2]). I
prefer (1), but I think programmatically (2) is much more symmetrical. I
am assuming (1) below.
If we have: (taking hint from [1])
CPU
|
====,============`============= PCI Bus 0
|
PCI-PCI
Bridge
|
=,='=======,====== PCI Bus 1
| |
SCSI Ethernet
PCI Bus 0 (rte_bus)pci_bus_0
`.-> scan(): this calls knows it is a PCI-PCI bridge. It would allocate
| a new pci_bus_1 (rte_bus object) and attach to bus_list.
| Then, assign generic SCSI scan functions to pci_bus_1->scan
| and pci_bus_1->match.
`-> eal/probe()
- bus->match() is called with rte_device/driver. In this
case, it would move over all the buses in bus_list pivoted
on pci_bus_0 and call rte_bus->match.
- (#) For each matched entry, subsequently call the
rte_bus->probe()
- (*) Cascading calls to rte_driver->probe() for pci_bus_1
(#) there is still an open discussion about whether bus->probe() should
exist or not. (I am not convinced buses should probe, but DPDK model
doesn't bode well without it)
(*) pci_bus_0->probe() would get rte_device/rte_driver as NULL and
rotate over each device/driver scanned in pci_bus_1 calling bus->probe.
[1] http://www.tldp.org/LDP/tlk/dd/pci.html
[2] http://dpdk.org/ml/archives/dev/2016-August/045947.html
(Note: I agree that there are minor holes in above theory, specifically
from implementation point. But, I am confident that with minor changes
this is achievable).
>
>>>
>>> Well, if you have no usecase at the moment, let's keep it simple, please.
>>>
>>
>> Ok.
>>
>>>
>>>>>
>>>>>> 0006: Integrate bus scan/match with EAL, without any effective
>>>>>> driver
>>>>>
>>>>>
>>>>>
>>>>> Hard to find a right balance in patch splittng, but patch 4 and 6 are
>>>>> linked, I would squash them into one.
>>>>
>>>>
>>>>
>>>> Yes, it is hard and sometimes there is simply no strong rationale for
>>>> splitting or merging. This is one of those cases.
>>>> My idea was that one patch _only_ introduces Bus services (structures,
>>>> functions etc) and another should enable the calls to it from EAL.
>>>> In that sense, I still think 4 and 6 should remain separate, may be
>>>> consecutive, though.
>>>
>>>
>>> Ok, will see in next version of the patchset.
>>
>>
>> Is there anything specific that you are looking for in patchset v2?
>> I was thinking of:
>> 0. fixing BSD compilation issue reported by CI
>> 1. improving the test_pci.c
>> 2. hotplugging
>> 3. trying to move PCI to drives/bus/pci/linux/* and resolving how drivers
>> link to it, and how EAL resources like devargs are consumed.
>>
>> Anything else?
>>
>>>
>>>
>>>>>
>>>>>> 0007: rte_pci_driver->probe replaced with rte_driver->probe
>>>>>
>>>>>
>>>>>
>>>>> This patch is too big, please separate in two patches: eal changes
>>>>> then ethdev/driver changes.
>>>>
>>>>
>>>>
>>>> I don't think that can be done. One change is incomplete without the
>>>> other.
>>>>
>>>> Changes to all files are only for rte_pci_driver->probe to
>>>> rte_driver->probe
>>>> movement. EAL changes is to allow rte_eth_dev_pci_probe function after
>>>> such
>>>> a change as rte_driver->probe has different arguments as compared to
>>>> rte_pci_driver->probe. The patches won't compile if I split.
>>>>
>>>> Am I missing something?
>>>>>
>>>>>
>>>>> Why do you push back the driver object in the 'probe' method ? (idem
>>>>> rte_bus->scan).
>>>>
>>>>
>>>>
>>>> I am assuming you are referring to rte_driver->probe().
>>>> This is being done so that implementations (specific to drivers on a
>>>> particular bus) can start extracting the rte_xxx_driver, if need be.
>>>>
>>>> For example, for e1000/em_ethdev.c, rte_driver->probe() have been set to
>>>> rte_eth_dev_pci_probe() which requires rte_pci_driver to work with. In
>>>> absence of the rte_driver object, this function cannot call
>>>> rte_pci_driver->probe (for example) for driver specific operations.
>>>
>>>
>>> Sorry, I am thinking a step ahead with eth_driver out of the picture.
>>> But once eth_driver disappears, I can see no reason to keep this
>>> driver in the probe method (Schizophrenia again).
>>
>>
>> When eth_driver disappears, i was thinking of accomodating the eth_dev_init
>> into the rte_pci_driver->probe/init.
>> But, this is still a nascent thought.
>> I am yet to start working on eth_driver.
>>
>>>
>>>
>>>
>>
>
Thanks for your comments.
-
Shreyansh