From: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
To: Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: kvm-devel
<kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Subject: Re: [RFC] Remove tx_timer from virtio_net
Date: Tue, 8 Jan 2008 08:54:09 +1100 [thread overview]
Message-ID: <200801080854.09550.rusty@rustcorp.com.au> (raw)
In-Reply-To: <47828D5D.5080700-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
On Tuesday 08 January 2008 07:36:45 Anthony Liguori wrote:
> Avi and I were talking this afternoon and he suggested that we should
> remove the tx_timer from the virtio_net front-end and replace it with a
> tx_timer in the backend.
>
> Since the backend can suppress notifications, this is appealing since it
> gives much more flexibility to the backend in determining how to do tx
> batching. I've done a quick implementation and performance is pretty good.
>
> We may need an ABI change, however. When the backend disables
> notifications, there is absolutely no way for the frontend to notify
> anymore. In the case where the queue fills up, it cannot flush since
> the backend has disabled notifications. To work around this, I had to
> least notifications enabled and check for the case where the queue fills
> up manually.
>
> I think a possible solution to this would be to differentiate between a
> soft and hard notify. We would introduce a VRING_USED_F_NOTIFY_ON_FULL
> and a VRING_AVAIL_F_NOTIFY_ON_FULL.
>
> The NO_NOTIFY variants would indicate that the other end never sends a
> notify, whereas NOTIFY_ON_FULL would indicate that the other end never
> sends a notify unless the queue fills up.
Hi Anthony,
I really like this (in proportion to my discomfort with the hrtimers hack,
in fact). The good news is that I don't think we need a significant ABI
change: I think we should have the vring_get_buf() failure path kick the
other end unconditionally.
This makes sense: the NO_INTERRUPT flag is really a "you don't need to
interrupt me" hint; you're allowed to interrupt even if it's set. So it
should be at worst harmless. It should work in the inter-guest case, for
example.
Rather than apply this, I will just drop the hrtimer patches, and do a
separate "kick on queue full" patch.
Thanks!
Rusty.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
prev parent reply other threads:[~2008-01-07 21:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-07 20:36 [RFC] Remove tx_timer from virtio_net Anthony Liguori
[not found] ` <47828D5D.5080700-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-01-07 21:54 ` Rusty Russell [this message]
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=200801080854.09550.rusty@rustcorp.com.au \
--to=rusty-8n+1lvoiyb80n/f98k4iww@public.gmane.org \
--cc=aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
--cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.