From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@gmail.com>,
mdroth <mdroth@linux.vnet.ibm.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Liu Ping Fan <qemulist@gmail.com>
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib
Date: Wed, 13 Mar 2013 19:52:04 +0200 [thread overview]
Message-ID: <20130313175204.GA7894@redhat.com> (raw)
In-Reply-To: <5140B80D.7000301@redhat.com>
On Wed, Mar 13, 2013 at 06:31:57PM +0100, Paolo Bonzini wrote:
> > We could do that purely
> > with AioContexts as well, but that rules out a large class of
> > backends that offloaded event loops can interact with, such as Chardevs,
> > so I think modelling how to handle both will provide a threading model
> > that scales better with other devices/subsystems.
>
> .. but I think the "no magic" argument applies here too. After all we
> only have a handful of subsystems. If chardevs are not performance
> critical, they can keep running in the main thread.
>
> If one day we find out that we need a real-time serial port, and glib
> just doesn't cut it, we shouldn't be ashamed of ripping GIOChannels out,
> hand-writing the same stuff, and using a dedicated AioContext. Of
> course by the time we get there we'll have unit tests/qtests to make
> sure we do not regress. Right??? :)
>
> Paolo
Since you mention serial port, just wanted to say that while it's
bandwidth requirements are not high, we do need to improve its latency.
ATM whenever someone tries to use the emulated serial, guest experiences
stalls and worst case latency jumps, and it's a pain point for many
users.
--
MST
next prev parent reply other threads:[~2013-03-13 17:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 5:59 [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib Liu Ping Fan
2013-03-13 5:59 ` [Qemu-devel] [RFC PATCH 1/2] net: port tap " Liu Ping Fan
2013-03-13 5:59 ` [Qemu-devel] [RFC PATCH 2/2] net: port hub " Liu Ping Fan
2013-03-13 10:58 ` [Qemu-devel] [RFC PATCH 0/2] port network layer " Paolo Bonzini
2013-03-13 12:34 ` Anthony Liguori
2013-03-13 16:21 ` Paolo Bonzini
2013-03-13 17:06 ` mdroth
2013-03-13 17:31 ` Paolo Bonzini
2013-03-13 17:52 ` Michael S. Tsirkin [this message]
2013-03-13 18:09 ` Anthony Liguori
2013-03-13 17:23 ` Anthony Liguori
2013-03-13 17:35 ` Paolo Bonzini
2013-03-13 17:52 ` Anthony Liguori
2013-03-14 9:29 ` Stefan Hajnoczi
2013-03-14 9:53 ` Paolo Bonzini
2013-03-13 17:58 ` Anthony Liguori
2013-03-13 18:08 ` Paolo Bonzini
2013-03-13 18:51 ` Anthony Liguori
2013-03-14 10:04 ` Peter Maydell
2013-03-14 10:53 ` Paolo Bonzini
2013-03-14 11:00 ` Peter Maydell
2013-03-14 11:04 ` Paolo Bonzini
2013-03-14 11:26 ` Peter Maydell
2013-03-15 9:13 ` Stefan Hajnoczi
2013-03-19 9:30 ` Markus Armbruster
2013-03-19 10:12 ` Peter Maydell
2013-03-19 10:34 ` Paolo Bonzini
2013-03-19 10:38 ` Peter Maydell
2013-03-19 10:45 ` Paolo Bonzini
2013-03-14 14:08 ` liu ping fan
2013-03-14 14:18 ` Paolo Bonzini
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=20130313175204.GA7894@redhat.com \
--to=mst@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
--cc=stefanha@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).