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

[Kamil Rytarowski <krytarowski@caviumnetworks.com>]

W dniu 03.02.2016 o 09:47, David Marchand pisze:
> Hello,
Hello,

> On Tue, Feb 2, 2016 at 3:27 PM,  <krytarowski@caviumnetworks.com> wrote:
>> From: Kamil Rytarowski <Kamil.Rytarowski@caviumnetworks.com>
>>
>> This change enables drivers needing custom pci (de)initialization functions
>> through the standard callback overloading.
>>
>> For example:
>>
>>   /*
>>    * virtual function driver struct
>>    */
>>   static struct eth_driver rte_DRIVER_pmd = {
>>          {
>>                  .name = "rte_DRIVER_pmd",
>>                  .id_table = pci_id_DRIVER_map,
>>                  .drv_flags = RTE_PCI_DRV_NEED_MAPPING,
>>                  .devinit = DRIVER_pci_devinit,
>>          },
>>          .eth_dev_init = eth_DRIVER_dev_init,
>>          .dev_private_size = sizeof(struct DRIVER),
>>   };
>>
>> Use-case is as follows: NIC offers several pci virtual functions, while
>> one of them is to be treated as port, we need to configure the rest in a
>> specific way for particular device for full interface (port) functionality.
> Mmm, why don't you register a custom pci driver rather than a eth_driver ?
Both Virtual Functions are of eth_driver type and they share the same 
PCI ID.

They are like 2 (or more) NIC devices working in tandem (it's not 
bonding), with a possibility to join into a single one and offer 
additional functionality. In that case one is master and the other is 
donor of functionality, like additional queue sets.

> And do your custom things in its devinit function ?
>
>
Yes, I'm doing custom things.

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

I cannot overload functions called after .devinit() as the secondary 
devices will be wrongly treated like a DPDK port.


My use-case doesn't need modified API to be functional.

The missing handling of overloaded .devinit and .devuninit looks like a 
bug - there is API for it, but it will keep overwriting the pointers 
with local functions (rte_eth_dev_init(), rte_eth_dev_uninit()).