From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-api@vger.kernel.org
Subject: Re: [PATCH net-next RFC 1/3] virtio: support for urgent descriptors
Date: Mon, 13 Oct 2014 14:22:12 +0800 [thread overview]
Message-ID: <543B6F94.2090107@redhat.com> (raw)
In-Reply-To: <20141012092744.GA9567@redhat.com>
On 10/12/2014 05:27 PM, Michael S. Tsirkin wrote:
> On Sat, Oct 11, 2014 at 03:16:44PM +0800, Jason Wang wrote:
>> Below should be useful for some experiments Jason is doing.
>> I thought I'd send it out for early review/feedback.
>>
>> event idx feature allows us to defer interrupts until
>> a specific # of descriptors were used.
>> Sometimes it might be useful to get an interrupt after
>> a specific descriptor, regardless.
>> This adds a descriptor flag for this, and an API
>> to create an urgent output descriptor.
>> This is still an RFC:
>> we'll need a feature bit for drivers to detect this,
>> but we've run out of feature bits for virtio 0.X.
>> For experimentation purposes, drivers can assume
>> this is set, or add a driver-specific feature bit.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> I see that as compared to my original patch, you have
> added a new flag: VRING_AVAIL_F_NO_URGENT_INTERRUPT
> I don't think it's necessary, see below.
>
> As such, I think this patch should be split:
> - original patch adding support for urgent descriptors
> - a patch adding virtqueue_enable/disable_cb_urgent(_prepare)?
Not sure this is a good idea, since the api of first patch is in-completed.
>
>> ---
>> drivers/virtio/virtio_ring.c | 75 +++++++++++++++++++++++++++++++++++++---
>> include/linux/virtio.h | 14 ++++++++
>> include/uapi/linux/virtio_ring.h | 5 ++-
>> 3 files changed, 89 insertions(+), 5 deletions(-)
>>
[...]
>>
>> +unsigned virtqueue_enable_cb_prepare_urgent(struct virtqueue *_vq)
>> +{
>> + struct vring_virtqueue *vq = to_vvq(_vq);
>> + u16 last_used_idx;
>> +
>> + START_USE(vq);
>> + vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_URGENT_INTERRUPT;
>> + last_used_idx = vq->last_used_idx;
>> + END_USE(vq);
>> + return last_used_idx;
>> +}
>> +EXPORT_SYMBOL_GPL(virtqueue_enable_cb_prepare_urgent);
>> +
> You can implement virtqueue_enable_cb_prepare_urgent
> simply by clearing ~VRING_AVAIL_F_NO_INTERRUPT.
>
> The effect is same: host sends interrupts only if there
> is an urgent descriptor.
Seems not, consider the case when event index was disabled. This will
turn on all interrupts.
WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: rusty@rustcorp.com.au, virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH net-next RFC 1/3] virtio: support for urgent descriptors
Date: Mon, 13 Oct 2014 14:22:12 +0800 [thread overview]
Message-ID: <543B6F94.2090107@redhat.com> (raw)
In-Reply-To: <20141012092744.GA9567@redhat.com>
On 10/12/2014 05:27 PM, Michael S. Tsirkin wrote:
> On Sat, Oct 11, 2014 at 03:16:44PM +0800, Jason Wang wrote:
>> Below should be useful for some experiments Jason is doing.
>> I thought I'd send it out for early review/feedback.
>>
>> event idx feature allows us to defer interrupts until
>> a specific # of descriptors were used.
>> Sometimes it might be useful to get an interrupt after
>> a specific descriptor, regardless.
>> This adds a descriptor flag for this, and an API
>> to create an urgent output descriptor.
>> This is still an RFC:
>> we'll need a feature bit for drivers to detect this,
>> but we've run out of feature bits for virtio 0.X.
>> For experimentation purposes, drivers can assume
>> this is set, or add a driver-specific feature bit.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> I see that as compared to my original patch, you have
> added a new flag: VRING_AVAIL_F_NO_URGENT_INTERRUPT
> I don't think it's necessary, see below.
>
> As such, I think this patch should be split:
> - original patch adding support for urgent descriptors
> - a patch adding virtqueue_enable/disable_cb_urgent(_prepare)?
Not sure this is a good idea, since the api of first patch is in-completed.
>
>> ---
>> drivers/virtio/virtio_ring.c | 75 +++++++++++++++++++++++++++++++++++++---
>> include/linux/virtio.h | 14 ++++++++
>> include/uapi/linux/virtio_ring.h | 5 ++-
>> 3 files changed, 89 insertions(+), 5 deletions(-)
>>
[...]
>>
>> +unsigned virtqueue_enable_cb_prepare_urgent(struct virtqueue *_vq)
>> +{
>> + struct vring_virtqueue *vq = to_vvq(_vq);
>> + u16 last_used_idx;
>> +
>> + START_USE(vq);
>> + vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_URGENT_INTERRUPT;
>> + last_used_idx = vq->last_used_idx;
>> + END_USE(vq);
>> + return last_used_idx;
>> +}
>> +EXPORT_SYMBOL_GPL(virtqueue_enable_cb_prepare_urgent);
>> +
> You can implement virtqueue_enable_cb_prepare_urgent
> simply by clearing ~VRING_AVAIL_F_NO_INTERRUPT.
>
> The effect is same: host sends interrupts only if there
> is an urgent descriptor.
Seems not, consider the case when event index was disabled. This will
turn on all interrupts.
next prev parent reply other threads:[~2014-10-13 6:22 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-11 7:16 [PATCH net-next RFC 0/3] virtio-net: Conditionally enable tx interrupt Jason Wang
2014-10-11 7:16 ` Jason Wang
2014-10-11 7:16 ` [PATCH net-next RFC 1/3] virtio: support for urgent descriptors Jason Wang
2014-10-11 7:16 ` Jason Wang
2014-10-12 9:27 ` Michael S. Tsirkin
2014-10-12 9:27 ` Michael S. Tsirkin
2014-10-13 6:22 ` Jason Wang [this message]
2014-10-13 6:22 ` Jason Wang
2014-10-13 7:16 ` Michael S. Tsirkin
2014-10-13 7:16 ` Michael S. Tsirkin
2014-10-15 5:40 ` Rusty Russell
2014-10-15 5:40 ` Rusty Russell
2014-10-17 5:23 ` Jason Wang
2014-10-11 7:16 ` [PATCH net-next RFC 2/3] vhost: support " Jason Wang
2014-10-11 7:16 ` Jason Wang
2014-10-11 7:16 ` [PATCH net-next RFC 3/3] virtio-net: conditionally enable tx interrupt Jason Wang
2014-10-11 7:16 ` Jason Wang
2014-10-11 14:48 ` Eric Dumazet
2014-10-11 14:48 ` Eric Dumazet
2014-10-13 6:02 ` Jason Wang
2014-10-13 6:02 ` Jason Wang
2014-10-14 21:51 ` Michael S. Tsirkin
2014-10-14 21:51 ` Michael S. Tsirkin
2014-10-15 3:34 ` Jason Wang
2014-10-15 3:34 ` Jason Wang
2014-10-14 18:53 ` [PATCH net-next RFC 0/3] virtio-net: Conditionally " David Miller
[not found] ` <1413011806-3813-1-git-send-email-jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-10-14 18:53 ` David Miller
2014-10-14 18:53 ` David Miller
2014-10-14 21:51 ` Michael S. Tsirkin
2014-10-14 21:51 ` Michael S. Tsirkin
2014-10-15 3:24 ` Jason Wang
2014-10-15 3:24 ` Jason Wang
2014-10-14 23:06 ` Michael S. Tsirkin
2014-10-14 23:06 ` Michael S. Tsirkin
2014-10-15 7:28 ` Jason Wang
2014-10-15 7:28 ` Jason Wang
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=543B6F94.2090107@redhat.com \
--to=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--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.