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

Doherty, Declan declan.doherty at intel.com
Wed Jun 25 16:41:43 CEST 2014

> -----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. 


More information about the dev mailing list