2014-06-25 14:41, Doherty, Declan: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 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: > > 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.
I'm sure it would be much cleaner if you split rte_eth_bond_slave_add() instead of splitting rte_eal_dev_init(). If I understand well, you should first save kvargs for slaves and add them at configure time. Then you could remove PMD_BDEV type and use PMD_VDEV. I know it's an additional work but API cleaning really deserves it. Thanks -- Thomas
