> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, June 25, 2014 2:55 PM > To: Doherty, Declan > Cc: dev at dpdk.org > Subject: Re: [PATCH v7 3/6] EAL support for link bonding device initialization > > Hi Declan, > > 2014-06-24 17:03, Declan Doherty: > > Updating functionality in EAL to support adding link bonding > > devices via ?vdev option. Link bonding devices will be > > initialized after all physical devices have been probed and > > initialized. > [...] > > > Not sure to understand why you need to split rte_eal_dev_init() in 2 steps. > Should it be possible to keep existing rte_eal_dev_init() behaviour and makes > further initialization when calling rte_eth_dev_configure()? > I've seen it's empty for bonding device: >
> Thanks > -- > Thomas Hi Thomas, that need to split rte_eal_dev_init into 2 steps doesn't come explicitly from the bonded device itself, as a bonded device could be created at any time during initialization, the issue arises from the fact that none of physical devices are allocated/initialized until after pci_probe_all_drivers() is called, this puts an explicit constraint on when it is possible to create a bonded device which has physical devices as slaves, as the phyiscal devices don't exist at the initial call to rte_eal_dev_init() and therefore can't be added as slaves to the bonded device. It isn't possible to keep the rte_eal_dev_init() behavior and use rte_eth_dev_configure() to complete initialization without radically changing the behavior of the bonding library, and the current functionality of rte_eth_bond_slave_add(), as this would need to no longer actually add a slave, but to save the name of a slave to be retrieved at some point in the future to be added as a slave to the bonded device. Declan