Xen-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: pvUSB backend performance
Date: Fri, 03 Jul 2015 06:27:20 +0200	[thread overview]
Message-ID: <55960F28.90209@suse.com> (raw)
In-Reply-To: <CAFLBxZac2g6jWvTUvt7dvU8PWP83tiUo9m8NbELsyUU1QT5Rgw@mail.gmail.com>

On 07/02/2015 06:41 PM, George Dunlap wrote:
> On Mon, Jun 29, 2015 at 2:36 PM, Juergen Gross <jgross@suse.com> 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

  reply	other threads:[~2015-07-03  4:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24 12:06 pvUSB backend performance Juergen Gross
2015-06-24 13:57 ` Konrad Rzeszutek Wilk
2015-06-25  3:36   ` Juergen Gross
2015-06-25  8:53 ` Dario Faggioli
2015-06-25 10:41   ` Juergen Gross
2015-06-29 13:22 ` George Dunlap
2015-06-29 13:36   ` Juergen Gross
2015-07-02 16:41     ` George Dunlap
2015-07-03  4:27       ` Juergen Gross [this message]
2015-06-29 13:46 ` David Vrabel
2015-06-29 13:53   ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55960F28.90209@suse.com \
    --to=jgross@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox