From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: pvUSB backend performance Date: Fri, 03 Jul 2015 06:27:20 +0200 Message-ID: <55960F28.90209@suse.com> References: <558A9D2A.2020006@suse.com> <559149DC.8000708@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 07/02/2015 06:41 PM, George Dunlap wrote: > On Mon, Jun 29, 2015 at 2:36 PM, Juergen Gross wrote: >> On 06/29/2015 03:22 PM, George Dunlap wrote: >>> I think in an ideal world the toolstack will use the kernel backend if >>> it's available, and fall back to a qemu backend if it's not available. >> >> >> In case the performance is regarded to be sufficient I won't retry to >> push a kernel backend. So there will be none in the near future. >> >> If the performance is not good enough I'll give the kernel backend >> another try. If it's being accepted I probably won't do the qemu one. > > So if you're asking for general advice about where we think you might > best spend your time, I don't have much of an opinion; I don't know > who your users are nor what your priorities are as a company. > > If you're asking, "Would support for a qemu pv backend be accepted > into libxl that was 30% slower than the kernel one", I would > personally say "absolutely" (that is, if it came to a discussion, I > would argue for it). As David says, not relying on the kernel is > reason enough to accept it. The performance only needs to be good > enough to be usable (i.e., the performance threshold for acceptance > would be a lot lower than the numbers you've shown here). Thanks, that was the the kind of answer I'd like to receive. > Do note that just because SuSE has abandoned the kernel path doesn't > preclude others from either using old "classic" kernels, or > forward-porting (and trying to push) the PV backends themselves. If > the kernel support shows up in libxl before the qemu backend is ready, > there's no reason to remove it until it's pretty clear that pvusbback > is well and truly dead. Sure. Juergen