[dpdk-dev] [PATCH 6/6] doc: introduction to prgdev

Chen, Jing D jing.d.chen at intel.com
Tue Mar 7 14:45:09 CET 2017


> > >
> > > > +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.
>

I don't object to introduce a pseudo bus for FPGA, but it's a matter of work 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 bus
probe, which is not friendly to introduce pseudo bus for an actual PCI device.
 
> /Bruce


More information about the dev mailing list