[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 linux ibm com>
> Reviewed-by: Boris Fiuczynski <fiuczy linux vnet ibm com>
> Reviewed-by: Bjoern Walk <bwalk linux vnet ibm com>
> Reviewed-by: Ján Tomko <jtomko 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]