[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit
Kamil Rytarowski
krytarowski at caviumnetworks.com
Wed Feb 3 12:39:55 CET 2016
W dniu 03.02.2016 o 09:47, David Marchand pisze:
> Hello,
Hello,
> On Tue, Feb 2, 2016 at 3:27 PM, <krytarowski at caviumnetworks.com> wrote:
>> From: Kamil Rytarowski <Kamil.Rytarowski at 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()).
More information about the dev
mailing list