Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)

[Neil Horman <nhorman@tuxdriver.com>]

On Mon, Jun 16, 2014 at 04:17:03PM +0000, Richardson, Bruce wrote:
> 
> 
> > -----Original Message-----
> <...snip...>
> > > this doesn't seem like an idea solution either. I'm not 100% clear why
> > > rte_eal_pci_probe is currently called by  the application code and not initiated
> > >  from within rte_eal_dev_init, if this was the case we would be able to figure
> > out
> > > a dependency tree for initialization of devices, based on the parsed input
> > > arguments without having extra user input to or multiple calls of
> > rte_eal_dev_init.
> > >
> > I agree, I think you should move it into its proper place within rte_eal_init,
> > though I think multiple calls to rte_eal_dev_init is perfectly acceptible in
> > this scenario.  You certainly could parse the command line to build a dependency
> > tree if you wish, though I don't think thats crruently overly complex. The current
> > dependency tree is static at (physical devices, virtual devices, probe, stacked
> > devices).  If you need something more complex later, you can re-write it freely
> > as it will be an internal library mechanism with no external visibility.
> > 
> 
> How useful is this going to be? The more complicated the ethdev stacking being done, the better suited it is to being done via the C APIs, via code which can do analysis of the hardware and cores at runtime and make logical decisions? After all, even if we do have applications being run to use bonded devices at runtime in place of physical ones, the bonded devices don't actually replace the physical ones, so some other application logic is needed to ensure that the application knows to only use the bonded devices. In most cases simply having a port-mask suffices, but not all apps will have a port-mask parameter, and for those that do, it introduces complexity for the user counting out interfaces and trying to work out what ports will have what numbers to set the appropriate bits in the portmask.

Honestly?  I don't know.  As Stephen indicates the command line options might
not be overly used, as its not always the best interface to select when building
an application.  But by the same token, not everyone is building an application
that needs dynamic configuration with DPDK.  My main concern here is one of
consistency, which is really what people look for in a package within a
distribution (i.e. Fedora, what I'm doing with the dpdk right now). You're
probably correct in that lots of people will use the C api to build bonded
interfaces since its a new api and they won't have been using bonds yet.  But
I'm concerned that, with a distributed package, lots of people might also be
porting legacy applications to use the DPDK, in which case they may very well
want to create static configurations within the dpdk to lower their porting
efforts.  Those people may well be very turned off by the fact that some, but
not all interfaces can use the command line to be configured.

In the end, its all about consistency in my mind.  I get that the --vdev command
line parameter perhaps isn't the most useful interface available, but its whats
there.  And if you start creating PMD's that use separate configuration
interfaces and abandon the ones before it, you'll wind up with a hodgepodge of
apis, all of which an application will have to be aware of to provide a full
robust feature set.

If --vdev stays, we should make it work for all the PMD's.  Most might not use
it, but some will, and those that do will appreciate the consistency you
provide.  If it just doesn't make sense to keep it around anymore, lets drop it
and replace it with something better.  Perhaps a configuration file interface
would be good, so that the initialization of the pmds and the creation of
interfaces is separated from the acutal application (thats actually a good idea
I think, as it implies that all an application needs to know about is
interfaces, not how they are constructed or stacked).  But lets not just quietly
start abandoning stuff because its inconvienient.  

Neil