[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit

[Kamil Rytarowski]

W dniu 03.02.2016 o 15:08, David Marchand pisze:
> On Wed, Feb 3, 2016 at 12:39 PM, Kamil Rytarowski
> <krytarowski at caviumnetworks.com> wrote:
>> W dniu 03.02.2016 o 09:47, David Marchand pisze:
>>> And do your custom things in its devinit function ?
>> I'm requesting from PF the mode of the device to be initialized. This part
>> is handled dynamically and depends of the current configuration in PF.
>>
>> In my use-case there are two device types: primary (master) and secondary
>> (slave). For the primary VF I'm creating a DPDK port normally, for secondary
>> I retain configured PCI device for further reuse (and there is no port
>> created).
> Well, again, if you don't want to associate a port to this pci
> resource, why are you registering a eth_driver ?
> A eth_driver driver supposes you have a 1 - 1 relation between ethdev
> and pci resource.
In my use-case one DPDK port optionally manages more than single PCI 
resource, and these PCI resources compose single interface.

Another example of overloaded .devinit is in app/test/test_pci.c:

/*
  * PCI test
  * ========
  *
  * - Register a driver with a ``devinit()`` function.
  *
  * - Dump all PCI devices.
  *
  * - Check that the ``devinit()`` function is called at least once.
  */

With the current implementation it won't work, as .devinit callback will 
be overwritten by the internal function.

> For your case, register a pci driver, then in your pci probing
> function (.devinit), depending on what you want to do, you can either
> do nothing (?) or create one or more ethdevs (see mlx* and cxgbe
> drivers).
>
>
>

This is what I'm doing right now.

I need to initialize PCI bars and interrupts (resources) - all having 
the same PCI ID and their functionality depending upon PF configuration. 
Depending on this state, I'm making further decisions in 
DRIVER_devinit() and whether to make from it a port or a resource to 
reuse by a master port.