[dpdk-dev] [PATCH v8 00/21] Device querying
Gaëtan Rivet
gaetan.rivet at 6wind.com
Wed Jun 27 13:29:13 CEST 2018
On Wed, Jun 27, 2018 at 11:55:02AM +0100, Bruce Richardson wrote:
> On Tue, Jun 26, 2018 at 06:56:03PM +0200, Gaetan Rivet wrote:
> > This patchset introduces a new EAL API for querying devices,
> > filtered by arbitrary properties.
> >
> > The following elements are introduced to this end:
> >
> > * A new object, "rte_class", is used to describe
> > the device class abstraction layer (eth, crypto, ...).
> >
> > * Both rte_bus and rte_class now offer a way to
> > list their devices and filter the result
> > using locally defined properties.
> >
> > * The rte_dev API now has an rte_dev_iterator, which
> > is the way for the user to define the device filter
> > and iterate upon the resulting set.
> >
> > As an example, the "eth" device class is implemented.
> >
> > Additionally, the device filters for
> >
> > + rte_bus_pci
> > + rte_bus_vdev
> > + rte_class_eth
> >
> > are implemented and can be used with some
> > properties each, to show how to extend those.
> >
> > Some example of filters:
> >
> > "bus=pci/class=eth"
> > "bus=pci"
> > "class=eth"
> > "class=eth,name=net_ring0"
> > "bus=pci,id=00:00.0"
> > "bus=vdev,driver=net_ring"
> >
> > ---
> >
> > v2:
> >
> > * Reworked the dev_iterate callback to simplify
> > its implementation.
> >
> > Now dev_iterate implementation do not need to learn
> > about the intricacies of the rte_dev_iterator.
> > The rte_dev_iterator is managed purely by the
> > rte_dev_iterator_next function. Buses and classes then
> > do not have to care about settings things right.
> >
> > Additionally, dev_iterate implementations do not
> > have to sanitize their dev string anymore, they
> > are prepared by the rte_dev layer prior, which also
> > reduces the number of dynamic allocations.
> >
> > v3:
> >
> > * Introduced central constructor priority list.
> > * Removed lightweight kvarg parsing utility,
> > using librte_kvargs instead.
> > * Reversed dependencies of librte_kvargs and
> > librte_eal.
> > * Fixed a few bugs.
> > * @Bruce: I have noted the request for meson support.
> > I will install it and attempt it once the bulk of the work is done.
> >
> > v4:
> >
> > * Fixed a few bugs, added relevant acks,
> > fixed some typos.
> > * Made each matching functions actually check for a proper
> > list of accepted properties.
> > * rte_kvargs now includes rte_eal directly and keeps rte_log.
> > * added generic string comparison function to rte_kvargs,
> > as some kind of comparison should probably be shared by many layers.
> >
> > v5:
> >
> > * Rebased on master
> > * Use strcspn instead of custom function.
> > * Introduce private generic rte_eth_dev iterator.
> > This could be generalized to other iterators
> > (port_next, owner_id-aware, etc).
> > * Attempted to support meson.build.
> > Got lost in the implicit variables declared
> > when inversing dependencies between kvargs and EAL.
> > Removed anything related to meson.
> > * Postponed genericization of work from
> > device query to device declaration.
> > Much bigger than anticipated, will let this
> > part get in first and iterate over it.
> >
> > v6:
> >
> > * Rebased on master
> > * Introduce RTE_PRIORITY_LAST, to explicitly set
> > the lowest constructor priority.
> > * Fix copyright notice for eth_privage.* files.
> >
> > v7:
> >
> > * Rebased on master
> > * Fix rte_kvargs_strcmp return value.
> > * Fix layer parsing error
> > devstr "bus=pci/onemorelayer" now tells
> > that the additional layer is not recognized.
> >
> > v8:
> >
> > * Rebased on master
> > * Cleaned kvargs use: introduced
> > a new parser function, that simplifies
> > using the library for DPDK devargs.
> > * Refactored devargs parsing in a single
> > function within rte_devargs.
> > This function is useful both for rte_dev
> > parsing its iterator, and for rte_devargs
> > parsing --dev parameters (not yet implemented).
> > * A few small bugfixes.
> >
>
> Hi Gaetan,
>
> did you test building with shared library builds? I get build failures for
> shared libs after applying this set. It appears you may still have a
> circular dependency between EAL and kvargs libs.
>
> /Bruce
Hi Bruce,
Ha, yes, I forgot about that, there is a simple fix, I will update it.
I have other fixes as well, a v9 is on its way.
--
Gaëtan Rivet
6WIND
More information about the dev
mailing list