search for: num_free

...ivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index e639584..335dcec 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -93,8 +93,6 @@ struct vring_virtqueue /* Host publishes avail event idx */ bool event; - /* Number of free buffers */ - unsigned int num_free; /* Head of free buffer list. */ unsigned int free_head; /* Number we've added since last sync. */ @@ -106,9 +104,6 @@ struct vring_virtqueue /* How to notify other side. FIXME: commonalize hcalls! */ void (*notify)(struct virtqueue *vq); - /* Index of the queue */ - int queue_index...

...ivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index e639584..335dcec 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -93,8 +93,6 @@ struct vring_virtqueue /* Host publishes avail event idx */ bool event; - /* Number of free buffers */ - unsigned int num_free; /* Head of free buffer list. */ unsigned int free_head; /* Number we've added since last sync. */ @@ -106,9 +104,6 @@ struct vring_virtqueue /* How to notify other side. FIXME: commonalize hcalls! */ void (*notify)(struct virtqueue *vq); - /* Index of the queue */ - int queue_index...

...1 proposal, too. But before getting > into that, I think we first need to deep dive into the implementation > and usage of _first/next/last. The usage would need to lock the vq > from the first to the end (otherwise, the returned info about the number > of available desc in the vq, i.e. num_free, would be invalid): > > lock(vq); > add_first(); > add_next(); > add_last(); > unlock(vq); > > However, I think the case isn't this simple, since we need to check more > things > after each add_xx() step. For example, if only one entry is available at the > ti...

...1 proposal, too. But before getting > into that, I think we first need to deep dive into the implementation > and usage of _first/next/last. The usage would need to lock the vq > from the first to the end (otherwise, the returned info about the number > of available desc in the vq, i.e. num_free, would be invalid): > > lock(vq); > add_first(); > add_next(); > add_last(); > unlock(vq); > > However, I think the case isn't this simple, since we need to check more > things > after each add_xx() step. For example, if only one entry is available at the > ti...

On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote: > On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote: > > > > So the way I see it, there are several issues: > > > > - internal wait - forces multiple APIs like kick/kick_sync > > note how kick_sync can fail but your code never checks return code > > - need to re-write the last descriptor - might

On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote: > On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote: > > > > So the way I see it, there are several issues: > > > > - internal wait - forces multiple APIs like kick/kick_sync > > note how kick_sync can fail but your code never checks return code > > - need to re-write the last descriptor - might

...t can support the 1.1 proposal, too. But before getting into that, I think we first need to deep dive into the implementation and usage of _first/next/last. The usage would need to lock the vq from the first to the end (otherwise, the returned info about the number of available desc in the vq, i.e. num_free, would be invalid): lock(vq); add_first(); add_next(); add_last(); unlock(vq); However, I think the case isn't this simple, since we need to check more things after each add_xx() step. For example, if only one entry is available at the time we start to use the vq, that is, num_free is 0 aft...

...> > into that, I think we first need to deep dive into the implementation > > > and usage of _first/next/last. The usage would need to lock the vq > > > from the first to the end (otherwise, the returned info about the number > > > of available desc in the vq, i.e. num_free, would be invalid): > > > > > > lock(vq); > > > add_first(); > > > add_next(); > > > add_last(); > > > unlock(vq); > > > > > > However, I think the case isn't this simple, since we need to check more > > > things...

...> > into that, I think we first need to deep dive into the implementation > > > and usage of _first/next/last. The usage would need to lock the vq > > > from the first to the end (otherwise, the returned info about the number > > > of available desc in the vq, i.e. num_free, would be invalid): > > > > > > lock(vq); > > > add_first(); > > > add_next(); > > > add_last(); > > > unlock(vq); > > > > > > However, I think the case isn't this simple, since we need to check more > > > things...

This change makes ring buffer reclaim threshold num_free configurable for better performance, while it's hard coded as 1/2 * queue now. According to our test with qemu + dpdk, packet dropping happens when the guest is not able to provide free buffer in avail ring timely. Smaller value of num_free does decrease the number of packet dropping during our...

This change makes ring buffer reclaim threshold num_free configurable for better performance, while it's hard coded as 1/2 * queue now. According to our test with qemu + dpdk, packet dropping happens when the guest is not able to provide free buffer in avail ring timely. Smaller value of num_free does decrease the number of packet dropping during our...

...But before getting >> into that, I think we first need to deep dive into the implementation >> and usage of _first/next/last. The usage would need to lock the vq >> from the first to the end (otherwise, the returned info about the number >> of available desc in the vq, i.e. num_free, would be invalid): >> >> lock(vq); >> add_first(); >> add_next(); >> add_last(); >> unlock(vq); >> >> However, I think the case isn't this simple, since we need to check more >> things >> after each add_xx() step. For example, if only...

...o/virtgpu_vq.c @@ -293,7 +293,7 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev, ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC); if (ret == -ENOSPC) { spin_unlock(&vgdev->ctrlq.qlock); - wait_event(vgdev->ctrlq.ack_queue, vq->num_free); + wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= outcnt + incnt); spin_lock(&vgdev->ctrlq.qlock); goto retry; } else { @@ -368,7 +368,7 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev, ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMI...

...o/virtgpu_vq.c @@ -293,7 +293,7 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev, ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC); if (ret == -ENOSPC) { spin_unlock(&vgdev->ctrlq.qlock); - wait_event(vgdev->ctrlq.ack_queue, vq->num_free); + wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= outcnt + incnt); spin_lock(&vgdev->ctrlq.qlock); goto retry; } else { @@ -368,7 +368,7 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev, ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMI...

...> into that, I think we first need to deep dive into the implementation >>>> and usage of _first/next/last. The usage would need to lock the vq >>>> from the first to the end (otherwise, the returned info about the number >>>> of available desc in the vq, i.e. num_free, would be invalid): >>>> >>>> lock(vq); >>>> add_first(); >>>> add_next(); >>>> add_last(); >>>> unlock(vq); >>>> >>>> However, I think the case isn't this simple, since we need to check more >&gt...

The vq->vq.num_free hasn't been changed when error happens, so it shouldn't be changed when handling the error. Fixes: 780bc7903a32 ("virtio_ring: Support DMA APIs") Cc: Andy Lutomirski <luto at kernel.org> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: stable at vger.kernel.org Signed-o...

On Thu, Jul 18, 2019 at 12:55:50PM +0000, ? jiang wrote: > This change makes ring buffer reclaim threshold num_free configurable > for better performance, while it's hard coded as 1/2 * queue now. > According to our test with qemu + dpdk, packet dropping happens when > the guest is not able to provide free buffer in avail ring timely. > Smaller value of num_free does decrease the number of packet...

On 2019/7/18 ??9:04, Michael S. Tsirkin wrote: > On Thu, Jul 18, 2019 at 12:55:50PM +0000, ? jiang wrote: >> This change makes ring buffer reclaim threshold num_free configurable >> for better performance, while it's hard coded as 1/2 * queue now. >> According to our test with qemu + dpdk, packet dropping happens when >> the guest is not able to provide free buffer in avail ring timely. >> Smaller value of num_free does decrease the...

On 2019/7/18 ??9:04, Michael S. Tsirkin wrote: > On Thu, Jul 18, 2019 at 12:55:50PM +0000, ? jiang wrote: >> This change makes ring buffer reclaim threshold num_free configurable >> for better performance, while it's hard coded as 1/2 * queue now. >> According to our test with qemu + dpdk, packet dropping happens when >> the guest is not able to provide free buffer in avail ring timely. >> Smaller value of num_free does decrease the...

On 2018/11/8 ??9:38, Tiwei Bie wrote: >>> + >>> + if (vq->vq.num_free < descs_used) { >>> + pr_debug("Can't add buf len %i - avail = %i\n", >>> + descs_used, vq->vq.num_free); >>> + /* FIXME: for historical reasons, we force a notify here if >>> + * there are outgoing parts to the buffer. Presumably the...