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.
