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

[Kamil Rytarowski]

W dniu 03.02.2016 o 16:49, Kamil Rytarowski pisze:
>
>
> 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.

After sending the mail I noted that I can work with the .init callback 
and I may be wrong.

I will have a closer look and I will check whether it will work for me.

Thank you,