From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 09/14] xen: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity Date: Mon, 25 Nov 2013 10:54:56 +0100 Message-ID: <1385373296.15201.15.camel@Solace> References: <20131118175544.31002.79574.stgit@Solace> <20131118181756.31002.15256.stgit@Solace> <528BA24A0200007800104A52@nat28.tlf.novell.com> <1385146552.21426.73.camel@Solace> <5293274E02000078001066C6@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9071438891809221136==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vksss-0006hi-Jr for xen-devel@lists.xenproject.org; Mon, 25 Nov 2013 09:55:14 +0000 In-Reply-To: <5293274E02000078001066C6@nat28.tlf.novell.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: Jan Beulich Cc: Marcus Granado , Justin Weaver , Ian Campbell , Li Yechen , George Dunlap , AndrewCooper , Juergen Gross , Ian Jackson , MattWilson , xen-devel , KeirFraser , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --===============9071438891809221136== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2sjvN+j5XwRYMVrrGeCt" --=-2sjvN+j5XwRYMVrrGeCt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On lun, 2013-11-25 at 09:32 +0000, Jan Beulich wrote: > >>> On 22.11.13 at 19:55, Dario Faggioli wrot= e: > > Therefore, I kept this interface as it was here, also considering that: > > - it's pretty late to re-re-redesign; > > - neither this nor the xc one are stable interfaces, so we can come > > back and revisit this later, if we want to. > >=20 > > Do you think this could be acceptable? >=20 > I wouldn't veto it, but I also dislike reduced flexibility when more > flexibility is obviously achievable without much effort. >=20 Ok, understood. Ok, I'm up for changing this then. So, let m ask a few questions, just to make sure ot get it right this time! ;-P You are saying the interface should look as follows: int xc_vcpu_setaffinity(xc_interface *xch, uint32_t domid, int vcpu, xc_cpumap_t cpumap_soft, xc_cpumap_t cpumap_hard, uint32_t flags); Where both cpumap_soft and cpumap_hard are IN/OUT parameters and, as far as OUT is concerned: - cpumap_hard will contain hard-affinity&online - cpumap_soft will contain what? (a) soft-affinity? (b) soft-affinity&online (c) soft-affinity&hard-affinity&online? I would make it (c), as (a) is what xc_vcpu_setaffinity() retrieves, while the '&online' part is particularly hard to get from other existing calls (either at libxc and libxl level). Among (b) and (c), (c) is what would be most useful for an high level caller (like libxl) to have it ready, but it's also true that, if I give (b) to it, it could in theory reconstruct (c) by himself (with the vice-versa not being true). Thoughts? Also, should I return something in either *only* of the maps when the corresponding flag is set (and of course fill both when both flags are)? Or do we always want to get something back (when non NULL, of course) and apply the content of flag only to the IN path (i.e., for setting either or both the afinities)? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-2sjvN+j5XwRYMVrrGeCt 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 v1.4.15 (GNU/Linux) iEYEABECAAYFAlKTHnAACgkQk4XaBE3IOsRSVQCeIwO+IWLx6LiYqWIjtuJuX8iU 7roAnR/uNf5YwFV66Hf8O22WoRK2UvFD =+uMb -----END PGP SIGNATURE----- --=-2sjvN+j5XwRYMVrrGeCt-- --===============9071438891809221136== 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 --===============9071438891809221136==--