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
