2017-03-02 12:03, Chen Jing D: > +Overview > +======== I think the first review pass of this series must be focused on the overview you give here (thanks for the detailed explanations).
I'll try to sum up while commenting. [...] The target is programmable devices. > +The major purpose of prgdev is to help DPDK users to load/upgrade RTL images > +for FPGA devices, or upgrade firmware for programmble NICs. This is a control plane feature. You want to have it in DPDK to allow dynamic programmation while running the device, right? [...] > +When the set of APIs is introduced, a general question is why we need it in > +DPDK community? Good question :) [...] > +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. > +Note that bind/unbind actions are different concept from that a whole device > +attach/detach. For example, ``rte_eal_dev_detach()``, which will try to > detach the > +drivers with device and remove the whole device from specific class of > devices > +(ethdev, for example). Then, the whole device is invisible until a new > 'probe' > +is activated. I do not understand. > +During the whole procedure of image upload/download, prgdev handler is always > +valid and apps can use it operate on programmable device. The reason why > unbind > +is necessary is it may break the hardware when programming is in progress > while > +other functions are active. Using programmble NIC as an example, it's a > little > +impossible to receive/forward packets for hardware while updating firmware. > In > +this case, apps need to detach ethdev function before firmware upgrading. > Again, > +prgdev handler is still valid, it's function-level detach, different from > +device-level detach. After finishing image download, original function needs > to > +attach back, either use same or different drivers, depends on personalities > +changed or not. For a programmble NIC, the driver may be the same. For FPGA, > it > +may not, see below examples to get more details. If the personality of the device is changed, it must be seen as a new device from e.g. the ethdev point of view, while keeping the same prgdev device. In other words, a device can have several interfaces at the same time (ethdev, cryptodev, eventdev, prgdev, whatever). I think we can dynamically create/destroy some interfaces while keeping track of the underlying device. > +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.
