[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit
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 >> 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,
[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit
W dniu 03.02.2016 o 15:08, David Marchand pisze: > On Wed, Feb 3, 2016 at 12:39 PM, Kamil Rytarowski > 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.
[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit
On Wed, Feb 3, 2016 at 12:39 PM, Kamil Rytarowski 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. 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). -- David Marchand
[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit
W dniu 03.02.2016 o 09:47, David Marchand pisze:
> Hello,
Hello,
> On Tue, Feb 2, 2016 at 3:27 PM, wrote:
>> From: Kamil Rytarowski
>>
>> 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()).
[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit
Hello,
On Tue, Feb 2, 2016 at 3:27 PM, wrote:
> From: Kamil Rytarowski
>
> 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 ?
And do your custom things in its devinit function ?
--
David Marchand
[dpdk-dev] [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit
From: Kamil Rytarowski
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.
Signed-off-by: Kamil Rytarowski
---
lib/librte_ether/rte_ethdev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 756b234..ac4aeab 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -351,8 +351,10 @@ rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
void
rte_eth_driver_register(struct eth_driver *eth_drv)
{
- eth_drv->pci_drv.devinit = rte_eth_dev_init;
- eth_drv->pci_drv.devuninit = rte_eth_dev_uninit;
+ if (!eth_drv->pci_drv.devinit)
+ eth_drv->pci_drv.devinit = rte_eth_dev_init;
+ if (!eth_drv->pci_drv.devuninit)
+ eth_drv->pci_drv.devuninit = rte_eth_dev_uninit;
rte_eal_pci_register(ð_drv->pci_drv);
}
--
1.9.1
