[dpdk-dev] [PATCH v7 3/6] EAL support for link bonding device initialization

Thomas Monjalon thomas.monjalon at 6wind.com
Wed Jun 25 18:00:40 CEST 2014


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


More information about the dev mailing list