[libvirt] [PATCH v3 06/12] conf: Introduce address caching for PCI extensions

Andrea Bolognani abologna at redhat.com
Thu Aug 16 15:03:01 UTC 2018


On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
> This patch provides a caching mechanism for the device address
> extensions uid and fid on S390. For efficient sparse address allocation,
> we introduce two hash tables for uid/fid which hold the address set
> information per domain. Also in order to improve performance of
> searching available value, we introduce our own callbacks for the two
> hashtables. In this way, uid/fid is saved in hash key and hash value
> could be any non-NULL pointer due to no operation on hash value. That is
> also the reason why we don't introduce hash value free callback.
> 
> Signed-off-by: Yi Min Zhao <zyimin at linux.ibm.com>
> Reviewed-by: Boris Fiuczynski <fiuczy at linux.vnet.ibm.com>
> Reviewed-by: Bjoern Walk <bwalk at linux.vnet.ibm.com>
> Reviewed-by: Ján Tomko <jtomko at redhat.com>
> ---
>  src/conf/domain_addr.c         | 85 ++++++++++++++++++++++++++++++++++++++++++
>  src/conf/domain_addr.h         |  9 +++++
>  src/libvirt_private.syms       |  1 +
>  src/qemu/qemu_domain_address.c |  7 ++++
>  4 files changed, 102 insertions(+)

I haven't looked into the hash table handling in detail but I
wonder if it's really necessary? IIUC you're using it just to
mark which uids and fids have been already used by a device,
which the PCI address allocation code does by setting bits
inside integer variables - having a custom hash table for the
same seems like overkill, and from the maintenance point of
view it would be great to have the logic for PCI address and
zPCI address allocation be similar unless diverging is strictly
necessary.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list