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

Richardson, Bruce bruce.richardson at intel.com
Mon Jun 16 20:07:51 CEST 2014


> -----Original Message-----
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Monday, June 16, 2014 10:48 AM
> To: Richardson, Bruce
> Cc: Doherty, Declan; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library
> (librte_eal/librte_ether link bonding support changes)
> 
> 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.
> 

The config file idea is one that's probably worth considering for the future.

The thing about the vpmd option the assumption that all PMDs are equal. It works well for creating pseudo-physical ethdevs, such as pcap, raw-socket or ring or other similar ethdevs, but I'm not sure it's a good abstraction for higher level functionality that we want to expose via an ethdev interface. However, what to do for all these is not a decision we need to make for 1.7 :-)


More information about the dev mailing list