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

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, June 25, 2014 9:01 AM
> To: Doherty, Declan
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 3/6] EAL support for link bonding device
> initialization
> 
> 2014-06-25 14:41, Doherty, Declan:
> > From: Thomas Monjalon [mailto:thomas.monjalon@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.
> 

Or else we could just go back to the earlier versions of the submission and accept the fact that some types of devices are designed to be used from code via an API and that we don't need to be able to set up every type of device via the application command-line. The code for this feature and rework to EAL has just got continually more complicated every time due to the need to continually workaround gotchas when trying to enable this for second-level ethdevs.

/Bruce