From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 2/4] sysctl/libxl: Add interface for returning IO topology data Date: Thu, 4 Dec 2014 12:55:53 +0100 Message-ID: <1417694153.31647.32.camel@Abyss.station> References: <1417556050-23364-1-git-send-email-boris.ostrovsky@oracle.com> <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4880993259704416736==" Return-path: In-Reply-To: <1417556050-23364-3-git-send-email-boris.ostrovsky@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com, keir@xen.org, ufimtseva@gmail.com List-Id: xen-devel@lists.xenproject.org --===============4880993259704416736== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jgGip5BffGeypJhUNu3O" --=-jgGip5BffGeypJhUNu3O Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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) >=20 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. >=20 > Add libxl_get_topology() to handle new interface and modify > libxl_get_cpu_topology() to be a wrapper around it. >=20 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. >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-jgGip5BffGeypJhUNu3O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlSAS8kACgkQk4XaBE3IOsR4DQCgijaZ7G5o35XKBvnkHqhlqOKT oeMAoI7O+Fe8C78oosEmxzxZ2jsOIhsu =4L4S -----END PGP SIGNATURE----- --=-jgGip5BffGeypJhUNu3O-- --===============4880993259704416736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4880993259704416736==--