From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH RFC 2/2] vhost: support urgent descriptors
Date: Mon, 22 Sep 2014 17:55:23 +0800 [thread overview]
Message-ID: <541FF20B.4080201@redhat.com> (raw)
In-Reply-To: <20140922065539.GA12057@redhat.com>
On 09/22/2014 02:55 PM, Michael S. Tsirkin wrote:
> On Mon, Sep 22, 2014 at 11:30:23AM +0800, Jason Wang wrote:
>> On 09/20/2014 06:00 PM, Paolo Bonzini wrote:
>>> Il 19/09/2014 09:10, Jason Wang ha scritto:
>>>>>>
>>>>>> - if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
>>>>>> + if (vq->urgent || !vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
>>>> So the urgent descriptor only work when event index was not enabled?
>>>> This seems suboptimal, we may still want to benefit from event index
>>>> even if urgent descriptor is used. Looks like we need return true here
>>>> when vq->urgent is true?
>>> Its ||, not &&.
>>>
>>> Without event index, all descriptors are treated as urgent.
>>>
>>> Paolo
>>>
>> The problem is if vq->urgent is true, the patch checks
>> VRING_AVAIL_F_NO_INTERRUPT bit. This bit were set unconditionally in
>> virtqueue_enable_cb() regardless of event index feature and cleared
>> unconditionally in virtqueue_disable_cb().
> The reverse actually, right?
Ah, right.
>
>> So virtqueue_enable_cb() was
>> used to not only publish a new event index but also enable the urgent
>> descriptor. And virtqueue_disable_cb() disabled all interrupts including
>> the urgent descriptor. Guest won't get urgent interrupts by just adding
>> virtqueue_add_outbuf_urgent() since what it needs is to enable and
>> disable interrupt for !urgent descriptor.
> Right, we want a new API that advances event index but does not
> set VRING_AVAIL_F_NO_INTERRUPT.
> IMO still want to set VRING_AVAIL_F_NO_INTERRUPT when handling tx
> interrupts, to avoid interrupt storms.
I see, so urgent descriptor needs to be disabled in this case. But vhost
parts need a little big changes, we could not just check
VRING_AVAIL_F_NO_INTERRUPT when vq->urgent is true. If event index is
enabled, we still need to check used event to make sure the current tx
delayed interrupt works.
But just re-using VRING_AVAIL_F_NO_INTERRUPT for urgent descriptor may
not work in some case. I see codes of virtqueue_get_buf() that may
breaks this:
/* If we expect an interrupt for the next entry, tell
host
* by writing event index and flush out the write
before
* the read in the next get_buf call. */
if (!(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)) {
vring_used_event(&vq->vring) = vq->last_used_idx;
virtio_mb(vq->weak_barriers);
}
Consider if only urgent descriptor is enabled, this will publish used
event which in fact enable lots of unnecessary interrupt. In fact I
don't quite understand how the above lines is used. Virtio-net stop the
queue before enable the tx interrupt in start_xmit(), so the above lines
will not run at all.
>> Btw, not sure "urgent" is a suitable name, since interrupt is often slow
>> in kvm guest. And in fact virtio-net will probably use "urgent"
>> descriptor for those packets (e.g stream packets who can be delayed a
>> little bit to batch more bytes from userspace) who was not urgent
>> compared to other packets.
>>
> Yes but we are asking for an interrupt before event index is reached
> because something is waiting for the packet to be transmitted.
> I couldn't come up with a better name.
>
Ok.
next prev parent reply other threads:[~2014-09-22 9:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 10:49 [PATCH RFC 1/2] virtio: support for urgent descriptors Michael S. Tsirkin
2014-07-01 10:49 ` Michael S. Tsirkin
2014-07-01 10:49 ` [PATCH RFC 2/2] vhost: support " Michael S. Tsirkin
2014-07-01 10:49 ` Michael S. Tsirkin
2014-09-19 7:10 ` Jason Wang
2014-09-19 7:10 ` Jason Wang
2014-09-20 10:00 ` Paolo Bonzini
2014-09-22 3:30 ` Jason Wang
2014-09-22 6:55 ` Michael S. Tsirkin
2014-09-22 9:55 ` Jason Wang [this message]
2014-09-22 11:24 ` Michael S. Tsirkin
2014-09-19 10:35 ` Jason Wang
2014-09-19 10:35 ` Jason Wang
2014-07-09 0:28 ` [PATCH RFC 1/2] virtio: support for " Rusty Russell
2014-07-09 0:28 ` Rusty Russell
2014-09-21 8:10 ` Michael S. Tsirkin
2014-09-21 8:10 ` Michael S. Tsirkin
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=541FF20B.4080201@redhat.com \
--to=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=virtualization@lists.linux-foundation.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.