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@xxxxxxxxxxxxx> > Reviewed-by: Boris Fiuczynski <fiuczy@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Bjoern Walk <bwalk@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> > --- > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
