search for: add_next

...ail desc id of the chain > } > > The new desc will be put to desc[tail].next, and we don't need to walk > from the head desc[head].next when inserting a new desc to the chain, right? > > > > > > As for the use, it would be better to do > > > > if (!add_next(vq, ...)) { > > add_last(vq, ...) > > kick > > wait > > } > > "!add_next(vq, ...)" means that the vq is full? No - it means there's only 1 entry left for the last descriptor. > If so, what would add_last() > do then? > > > Using VI...

...ail desc id of the chain > } > > The new desc will be put to desc[tail].next, and we don't need to walk > from the head desc[head].next when inserting a new desc to the chain, right? > > > > > > As for the use, it would be better to do > > > > if (!add_next(vq, ...)) { > > add_last(vq, ...) > > kick > > wait > > } > > "!add_next(vq, ...)" means that the vq is full? No - it means there's only 1 entry left for the last descriptor. > If so, what would add_last() > do then? > > > Using VI...

...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 after add_first(),...

...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 after add_first(),...

...ng 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 after add_first(), we wouldn't be able to add_next...

...st/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...

...st/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...

...ementation >> 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, n...

...ur code never checks return code - need to re-write the last descriptor - might not work for alternative layouts which always expose descriptors immediately - some kind of iterator type would be nicer instead of maintaining head/prev explicitly As for the use, it would be better to do if (!add_next(vq, ...)) { add_last(vq, ...) kick wait } Using VIRTQUEUE_DESC_ID_INIT seems to avoid a branch in the driver, but in fact it merely puts the branch in the virtio code. -- MST

...ur code never checks return code - need to re-write the last descriptor - might not work for alternative layouts which always expose descriptors immediately - some kind of iterator type would be nicer instead of maintaining head/prev explicitly As for the use, it would be better to do if (!add_next(vq, ...)) { add_last(vq, ...) kick wait } Using VIRTQUEUE_DESC_ID_INIT seems to avoid a branch in the driver, but in fact it merely puts the branch in the virtio code. -- MST

...t. 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 >>&...

...esc id of the chain unsigned int tail; // tail desc id of the chain } The new desc will be put to desc[tail].next, and we don't need to walk from the head desc[head].next when inserting a new desc to the chain, right? > > As for the use, it would be better to do > > if (!add_next(vq, ...)) { > add_last(vq, ...) > kick > wait > } "!add_next(vq, ...)" means that the vq is full? If so, what would add_last() do then? > Using VIRTQUEUE_DESC_ID_INIT seems to avoid a branch in the driver, but > in fact it merely puts the branch in the virtio code...

On Wed, Jul 12, 2017 at 08:40:18PM +0800, Wei Wang wrote: > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index 28b0e96..9f27101 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -57,8 +57,28 @@ int virtqueue_add_sgs(struct virtqueue *vq, > void *data, > gfp_t gfp); > > +/* A desc with this init id is treated

On Wed, Jul 12, 2017 at 08:40:18PM +0800, Wei Wang wrote: > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index 28b0e96..9f27101 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -57,8 +57,28 @@ int virtqueue_add_sgs(struct virtqueue *vq, > void *data, > gfp_t gfp); > > +/* A desc with this init id is treated