[dpdk-dev] [PATCH v8 00/21] Device querying

Bruce Richardson bruce.richardson at intel.com
Wed Jun 27 12:55:02 CEST 2018


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


More information about the dev mailing list