2017-03-07 11:12, Bruce Richardson: > On Tue, Mar 07, 2017 at 10:34:06AM +0000, Chen, Jing D wrote: > > From: Thomas Monjalon > > > > +Any devices, having the capability to store/load a piece of info > > > > +to/from the deivce then changed hardware behavior, and applicable to > > > > +prgdev programming model, could be registered as a prgdev device. > > > > + > > > > +The device can be programmed (dynamic) within DPDK or have been prior > > > > +programmed > > > > +(static) prior to a DPDK application being launched. > > > [...] > > > > +Besides the simple API to upload/download image, the prgdev also > > > > +introduces a mechanism internally to switch drivers and > > > > +register/unregister device on the fly. With this mechanism, apps can > > > > +use the programmable device, unbind other personalities on demand, > > > then program it and bind it back with new personalities. > > > > +Apps can follow below examples to simply complete the whole process. > > > > > > I disagree about the specific bind/unbind for prgdev. > > > We must improve binding inside DPDK for every devices. > > > > First of all, let us try to imagine what is the safe status for device > > before apps > > intending to download some image to it - apps wouldn't operate on the > > device, > > any behaviors like configuring registers, receive/transmit data may impair > > the > > device or make the download failed. > > Following first answer to prevent app accessing device during image > > downloading, how can we achieve that? Detach drivers with device is a smart > > idea, right? But the problem is how can apps use prgdev API to download > > image > > after all drivers detached with the device? > > So, the final question is how can we just detached others driver except > > prgdev > > one? I can't find answer in current DPDK framework, that's why I'd like to > > introduce > > bind/unbind functions to detach other drivers from the device. > > > > I'm open to this problem. If any suggestion or mechanism can help on it, I > > can > > remove these 2. > > > > BTW, not all devices or image download actions need the device to detach > > the > > device, depending on hardware implementation.
Thanks for the explanations. It sounds interesting. > > > > +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. > > Sounds like we would need an FPGA bus driver in that case. I think that > would be a better solution than having a specific device driver loading > other drivers. Good suggestion. What do you think of a FPGA bus to consider more parameters than the PCI BDF when matching a device driver? How other systems manage the drivers for a FPGA-programmed device?
