lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20150210101839.GA9505@redhat.com> Date: Tue, 10 Feb 2015 11:18:39 +0100 From: "Michael S. Tsirkin" <mst@...hat.com> To: Rusty Russell <rusty@...tcorp.com.au> Cc: Jason Wang <jasowang@...hat.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, virtualization@...ts.linux-foundation.org, pagupta@...hat.com Subject: Re: [PATCH RFC v5 net-next 1/6] virtio_ring: fix virtqueue_enable_cb() when only 1 buffers were pending On Tue, Feb 10, 2015 at 11:33:52AM +1030, Rusty Russell wrote: > Jason Wang <jasowang@...hat.com> writes: > > We currently does: > > > > bufs = (avail->idx - last_used_idx) * 3 / 4; > > > > This is ok now since we only try to enable the delayed callbacks when > > the queue is about to be full. This may not work well when there is > > only one pending buffer in the virtqueue (this may be the case after > > tx interrupt was enabled). Since virtqueue_enable_cb() will return > > false which may cause unnecessary triggering of napis. This patch > > correct this by only calculate the four thirds when bufs is not one. > > I mildly prefer to avoid the branch, by changing the calculation like > so: > > /* Set bufs >= 1, even if there's only one pending buffer */ > bufs = (bufs + 1) * 3 / 4; Or bus * 3/4 + 1 > But it's not clear to me how much this happens. I'm happy with the > patch though, as currently virtqueue_enable_cb_delayed() is the same > as virtqueue_enable_cb() if there's only been one buffer added. > > Cheers, > Rusty. But isn't this by design? The documentation says: * This re-enables callbacks but hints to the other side to delay * interrupts until most of the available buffers have been processed; Clearly, this implies that when there's one buffer it must behave exactly the same. So I'm not very happy - this changes the meaning of the API without updating the documentation. > > Signed-off-by: Jason Wang <jasowang@...hat.com> > > --- > > drivers/virtio/virtio_ring.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 00ec6b3..545fed5 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -636,7 +636,10 @@ bool virtqueue_enable_cb_delayed(struct virtqueue *_vq) > > * entry. Always do both to keep code simple. */ > > vq->vring.avail->flags &= cpu_to_virtio16(_vq->vdev, ~VRING_AVAIL_F_NO_INTERRUPT); > > /* TODO: tune this threshold */ > > - bufs = (u16)(virtio16_to_cpu(_vq->vdev, vq->vring.avail->idx) - vq->last_used_idx) * 3 / 4; > > + bufs = (u16)(virtio16_to_cpu(_vq->vdev, vq->vring.avail->idx) - > > + vq->last_used_idx); > > + if (bufs != 1) > > + bufs = bufs * 3 / 4; > > vring_used_event(&vq->vring) = cpu_to_virtio16(_vq->vdev, vq->last_used_idx + bufs); > > virtio_mb(vq->weak_barriers); > > if (unlikely((u16)(virtio16_to_cpu(_vq->vdev, vq->vring.used->idx) - vq->last_used_idx) > bufs)) { > > -- > > 1.8.3.1 > > > > _______________________________________________ > > Virtualization mailing list > > Virtualization@...ts.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/virtualization -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists