From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 720F0108A for ; Tue, 7 Mar 2017 14:45:37 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 05:45:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,258,1484035200"; d="scan'208";a="57097221" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga002.jf.intel.com with ESMTP; 07 Mar 2017 05:45:30 -0800 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 7 Mar 2017 05:45:14 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 7 Mar 2017 05:45:14 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.204]) with mapi id 14.03.0248.002; Tue, 7 Mar 2017 21:45:10 +0800 From: "Chen, Jing D" To: "Richardson, Bruce" CC: Thomas Monjalon , "dev@dpdk.org" , "Liang, Cunming" , "Rogers, Gerald" , "Wiles, Keith" , "Mcnamara, John" Thread-Topic: [dpdk-dev] [PATCH 6/6] doc: introduction to prgdev Thread-Index: AQHSk0U8EZiYFBGnPUiwkBf6WHmbxaGHb3CAgAGwBCD//5tSgIAAr35w Date: Tue, 7 Mar 2017 13:45:09 +0000 Message-ID: <4341B239C0EFF9468EE453F9E9F4604D3C5FED99@shsmsx102.ccr.corp.intel.com> References: <1488427438-13646-1-git-send-email-jing.d.chen@intel.com> <1488427438-13646-7-git-send-email-jing.d.chen@intel.com> <1488825967.6DAzsKhpGM@xps13> <4341B239C0EFF9468EE453F9E9F4604D3C5FEB70@shsmsx102.ccr.corp.intel.com> <20170307111231.GA254436@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20170307111231.GA254436@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2MwNTg0ZDQtYzgwMi00N2ZiLTgwNjktZDYyYzNiNGViNTAxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImJHT2ZNWlJPUU9udmhGXC9aTjlnN09HTnE0M0tkaXJ2ZW9KQW9NZHFmZVBvPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 6/6] doc: introduction to prgdev X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 13:45:38 -0000 > > > > > > > +Another reason to provide bind/unbind action is programmble > > > > +devices, like FPGA, are not identified driver by 'vendor ID' and > > > > +'device ID', they might not be changed in all the ways, even FPGA > > > > +is fully programmed. So, it depends on internal mechanism of > > > > +FPGA, not 'vendor ID' and 'device ID' to identify proper drivers, > > > > +either a register value or signature, depending on FPGA hardware > > > > +design. In this case, EAL or other bus driver doesn't have the > > > > +capability to identify proper driver for FPGA device. With prgdev > > > > +introduced, while FPGA is always a prgdev, FPGA can use prgdev as > > > > +primary driver, to find proper > > > function driver. > > > > > > You mean prgdev should help the bus layer to map the right driver > interface? > > > It looks weird and dangerous. The standard way to identify a PCI > > > device is to look at its IDs. Other unknown methods must be strongly > discussed. > > > > For programmable Ethernet device, it's not truce. But for FPGA, it's. > > When FPGA is produced, the device ID indicate what model it is and > > won't be changed anyway, even being reprogrammed. It used some > > not-generic mechanism, like AFU id to distinguish the personalities. > > So, for FPGA, a prgdev driver can be used as primary driver to identify > personalities and then register to specific devices. >=20 > Sounds like we would need an FPGA bus driver in that case. I think that w= ould > be a better solution than having a specific device driver loading other d= rivers. > I don't object to introduce a pseudo bus for FPGA, but it's a matter of wor= k that FPGA driver needs to consider, not in scope of prgdev. Besides that, I can see DPDK EAL will do other bus probe first, then PCI bu= s probe, which is not friendly to introduce pseudo bus for an actual PCI devi= ce. =20 > /Bruce