Re: [PATCH 2/4] sysctl/libxl: Add interface for returning IO topology data

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1962 bytes --]

On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
> CPU and IO topology (support for returning the latter is added in the
> subsequent patch)
> 
Is it always the case that we need the full information (i.e., both CPU
and IO topology), at all levels above Xen?

I appreciate the performance implications (one hcall instead of two) in
cases where we do, but I still think, as Andrew suggested, that having a
new XEN_SYSCTL_iotopology (or something like that) and leaving
*_topologyinfo alone would make a better low-level interface.

All IMHO, of course.

> To do so move (and rename) previously used cpu_to_core/cpu_to_socket/
> cpu_to_node into struct xen_sysctl_cputopo and move it, together with
> newly added struct xen_sysctl_iotopo, to xen_sysctl_topologyinfo.
> 
> Add libxl_get_topology() to handle new interface and modify
> libxl_get_cpu_topology() to be a wrapper around it.
> 
This is, I think, useful, and I'd go for it, even if we adding a new
hypercall at the Xen and xc level.

Of course, it would work the other way round: the new libxl function
would wrap the existing libxl_get_cpu_topology() and a new libxl call
(something like libxl_get_io_topology() ?).

> Adjust xenpm and python's low-level C libraries for new interface.
> 
All in one patch? Wouldn't splitting it at least in two (hypervisor and
tools parts) be better? If it were me, I'd probably split even more...

> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>
Which would not be the case if we take the approach of adding a new,
iotopology specific, hcall, would it?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel