From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 5/7] libxl/libxc: Move libxl_get_cpu_topology()'s hypercall buffer management to libxc Date: Mon, 23 Feb 2015 17:14:58 +0000 Message-ID: <1424711698.27930.236.camel@citrix.com> References: <1423512275-6531-1-git-send-email-boris.ostrovsky@oracle.com> <1423512275-6531-6-git-send-email-boris.ostrovsky@oracle.com> <1424709863.27930.214.camel@citrix.com> <54EB5AC9.7070409@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54EB5AC9.7070409@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, ufimtseva@gmail.com, port-xen@netbsd.org, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, dario.faggioli@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, jbeulich@suse.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org On Mon, 2015-02-23 at 11:52 -0500, Boris Ostrovsky wrote: > On 02/23/2015 11:44 AM, Ian Campbell wrote: > > On Mon, 2015-02-09 at 15:04 -0500, Boris Ostrovsky wrote: > > > > What is the rationale for this change? > > libxl is not the right place to handle hypervisor-specific details like > buffer management (most, if not all, of other services that libxl > provides push these sort of things to libxc). It is acceptable for callers to do the buffer management themselves in principal. The primary reason to do so would be high frequency calls where the bouncing would be unacceptable overhead on every iteration (i.e. it allows callers to preallocate a single buffer). There aren't many such interfaces though and as you say most of them are in libxc (as it happens). Nonetheless the argument for this changw should be made in terms of the interface not being called frequently and therefore being tolerant of the bouncing overhead which simplifies things for the caller at the expense of the performance. That's assuming these interfaces are indeed tolerant of the performance hit... > > > (i.e. it should be part of the > > commit message) > > Yes. > > -boris