Re: [PATCH 6/6] doc: introduction to prgdev

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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?