search for: add_first

...hink 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 a...

...hink 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 a...

...Actually it wasn't intended to improve performance. It is used to indicate > the "init" state > of the chain. So, when virtqueue_add_chain_desc(, head_id,..) finds head > id=INIT, it will > assign the grabbed desc id to &head_id. In some sense, it is equivalent to > add_first(). > > Do you have a different opinion here? > > Best, > Wei > It is but let's make it explicit here - an API function is better than a special value. -- MST

...Actually it wasn't intended to improve performance. It is used to indicate > the "init" state > of the chain. So, when virtqueue_add_chain_desc(, head_id,..) finds head > id=INIT, it will > assign the grabbed desc id to &head_id. In some sense, it is equivalent to > add_first(). > > Do you have a different opinion here? > > Best, > Wei > It is but let's make it explicit here - an API function is better than a special value. -- MST

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

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

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

...eep 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 u...

...; 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...

On Wed, Jul 12, 2017 at 09:29:00PM +0800, Wei Wang wrote: > On 07/12/2017 09:06 PM, Michael S. Tsirkin wrote: > > 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 > >

On Wed, Jul 12, 2017 at 09:29:00PM +0800, Wei Wang wrote: > On 07/12/2017 09:06 PM, Michael S. Tsirkin wrote: > > 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 > >

...he virtio code. > Actually it wasn't intended to improve performance. It is used to indicate the "init" state of the chain. So, when virtqueue_add_chain_desc(, head_id,..) finds head id=INIT, it will assign the grabbed desc id to &head_id. In some sense, it is equivalent to add_first(). Do you have a different opinion here? Best, Wei