[dpdk-dev] [PATCH v1 00/15] rte_driver/device infrastructure

[Jan Viktorin]

On Fri, 15 Jul 2016 15:19:14 +0200
Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:

> 2016-07-08 21:09, Jan Viktorin:
> > Hello,
> > 
> > based on the discussions with Shreyansh, I propose a patchset with
> > the important EAL changes. It is incomplete and I suppose to extend
> > and change certain things in the foreseeable future.
> > 
> > Important notes:
> > 
> > * pmd_type is removed
> > * introduced rte_vdev_driver inheriting rte_driver
> > * PMD_REGISTER_DRIVER is replaced by RTE_EAL_VDRV_REGISTER
> > * rte_driver/device integrated into rte_pci_driver/device
> > * all drivers and devices are in 2 lists - general and bus-specific
> > 
> > Shreyansh, I hope I do not duplicate your work. I tried to avoid touching
> > pmd_type but it quite complicated... There is also an initial generalization
> > of rte_pci_resource. More such generalizations are to be done.
> > 
> > The init/uninit functions cannot be generalized easily, I think. Both PCI
> > and VDEV have different requirements.
> > 
> > No idea about hotplug...  
> 
> Please could you give a clear overview of how you split the work in
> your respective series?

Yes, it's a bit messy... My quick summary follows.

> 
> I take the opportunity to put my notes about some initial targets of
> this refactoring:
> 
> module/drivers
> 	attached to 1 bus: pci_driver or vdev_driver

pci_driver is done by Shreyansh/David
vdev_driver is done by myself

> 	rte_device = device resources / embedded in pci/vdev_driver

Extraction of rte_device is done by myself

> 		attached to n device interfaces (ethdev, crypto)
> 	1 device resource -> n device interfaces

I am not sure, what those two points means exactly.

> 	hotplug resource -> lookup drivers list
> 		per-bus lists or 1 list?

Not sure. At least partially done by Shreyansh/David.

> 	devinit/devuninit generalized and moved to rte_driver
> 		-> rename to probe/remove  

Some renames done by Shreyansh/David.

There will be no move. The vdev_driver has different kind of init/uninit
then PCI. So I cannot see a simple way how to generalize this.

I'll do the final init->probe, uninit->remove renames.

> 	crypto.dev_type could be dropped

I am not sure about this.

> 	drv_flags should be moved to rte_driver

I'll do.

> 	intr_init can be moved earlier in init, before affinity set
> devices

Done by Shreyansh/David.

> 	unique_device_name -> standard naming?

Done for PCI: rte_eal_pci_device_name by Shreyansh/David.

> 		difference with port_id ? -> device id for ethdev

Not sure.

> 		should be unique_resource_name -> 1 EAL resource may match several devices

Not sure.

> 	ethdev manage an interface, eal manage a hardware resource, device object in between?

Not sure about the question.

> 	need for bus object?

I don't think so at this stage.

> 	no need of driver object, module object?

The current rte_driver will not exist. Same for any kind of module.

> 	devargs, intr_handle, numa_node should be moved to rte_device

Yes, done by myself.

> hotplug notification to do
> 	notify free-able ressource?
> 	remove blacklist at EAL level and let application handle it
> 	devargs still in hotplug function, must be moved in separate API
> devargs
> 	new API
> 	new command line parameters
> 



-- 
   Jan Viktorin                  E-mail: Viktorin at RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic