search for: get_vq_desc

On 2020/6/10 ??7:05, Michael S. Tsirkin wrote: >>> +EXPORT_SYMBOL_GPL(vhost_get_vq_desc); >>> /* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */ >>> void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n) >>> { >>> + unfetch_descs(vq); >>> vq->last_avail_idx -= n; >> So unfetch_descs() has...

On 2020/6/10 ??7:05, Michael S. Tsirkin wrote: >>> +EXPORT_SYMBOL_GPL(vhost_get_vq_desc); >>> /* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */ >>> void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n) >>> { >>> + unfetch_descs(vq); >>> vq->last_avail_idx -= n; >> So unfetch_descs() has...

On Thu, Jun 11, 2020 at 11:02:57AM +0800, Jason Wang wrote: > > On 2020/6/10 ??7:05, Michael S. Tsirkin wrote: > > > > +EXPORT_SYMBOL_GPL(vhost_get_vq_desc); > > > > /* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */ > > > > void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n) > > > > { > > > > + unfetch_descs(vq); > > > > vq->last_avail_idx -=...

...so we call fetch_buf() here > * fetch_buf gets less than vhost_vq_num_batch_descs(vq); descriptors. ret = 1 > * This loop calls again fetch_buf, but vq->ndescs > 0 (and avail_vq == > last_avail_vq), so it just return 1 That's what [PATCH RFC v7 08/14] fixup! vhost: use batched get_vq_desc version is supposed to fix. -- MST

...s(struct vhost_virtqueue *vq) > { > kfree(vq->descs); Batching is enabled if max_descs > UIO_MAXIOV. So this uses batching for test. But net is unchanged, so it is still not using the batched version. Is that right? I think a better subject would be "vhost/test: use batched get_vq_desc version". And that explains which testing it refers to: the one executed by vhost test. I think there was a separate patch to enable that for net separately, but it got lost - or did I miss it? -- MST

...han vhost_vq_num_batch_descs(vq); descriptors. ret = 1 > > > * This loop calls again fetch_buf, but vq->ndescs > 0 (and avail_vq == > > > last_avail_vq), so it just return 1 > > > > That's what > > [PATCH RFC v7 08/14] fixup! vhost: use batched get_vq_desc version > > is supposed to fix. > > > > Sorry, I forgot to include that fixup. > > With it I don't see CPU stalls, but with that version latency has > increased a lot and I see packet lost: > + ping -c 5 10.200.0.1 > PING 10.200.0.1 (10.200.0.1) 56(84) bytes o...

On 2020/6/20 ??2:07, Eugenio Perez Martin wrote: > On Mon, Jun 15, 2020 at 2:28 PM Eugenio Perez Martin > <eperezma at redhat.com> wrote: >> On Thu, Jun 11, 2020 at 5:22 PM Konrad Rzeszutek Wilk >> <konrad.wilk at oracle.com> wrote: >>> On Thu, Jun 11, 2020 at 07:34:19AM -0400, Michael S. Tsirkin wrote: >>>> As testing shows no performance change,

On Fri, Jun 19, 2020 at 08:07:57PM +0200, Eugenio Perez Martin wrote: > On Mon, Jun 15, 2020 at 2:28 PM Eugenio Perez Martin > <eperezma at redhat.com> wrote: > > > > On Thu, Jun 11, 2020 at 5:22 PM Konrad Rzeszutek Wilk > > <konrad.wilk at oracle.com> wrote: > > > > > > On Thu, Jun 11, 2020 at 07:34:19AM -0400, Michael S. Tsirkin wrote: >

On Wed, Jun 17, 2020 at 11:19:26AM +0800, Jason Wang wrote: > > On 2020/6/11 ??7:34, Michael S. Tsirkin wrote: > > static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq) > > { > > kfree(vq->descs); > > @@ -394,6 +400,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev) > > for (i = 0; i < dev->nvqs; ++i) { > > vq =

On 2020/6/23 ??3:00, Eugenio Perez Martin wrote: > On Tue, Jun 23, 2020 at 4:51 AM Jason Wang <jasowang at redhat.com> wrote: >> >> On 2020/6/23 ??12:00, Michael S. Tsirkin wrote: >>> On Wed, Jun 17, 2020 at 11:19:26AM +0800, Jason Wang wrote: >>>> On 2020/6/11 ??7:34, Michael S. Tsirkin wrote: >>>>> static void

On Tue, Jun 23, 2020 at 09:00:57AM +0200, Eugenio Perez Martin wrote: > On Tue, Jun 23, 2020 at 4:51 AM Jason Wang <jasowang at redhat.com> wrote: > > > > > > On 2020/6/23 ??12:00, Michael S. Tsirkin wrote: > > > On Wed, Jun 17, 2020 at 11:19:26AM +0800, Jason Wang wrote: > > >> On 2020/6/11 ??7:34, Michael S. Tsirkin wrote: > > >>>

On Fri, Jul 10, 2020 at 07:39:26AM +0200, Eugenio Perez Martin wrote: > > > How about playing with the batch size? Make it a mod parameter instead > > > of the hard coded 64, and measure for all values 1 to 64 ... > > > > > > Right, according to the test result, 64 seems to be too aggressive in > > the case of TX. > > > > Got it, thanks both!

On 2020/7/10 ??1:39, Eugenio Perez Martin wrote: > It is allocated 1 thread in lcore 1 (F_THREAD=1) which belongs to the > same NUMA as testpmd. Actually, it is the testpmd master core, so it > should be a good idea to move it to another lcore of the same NUMA > node. > > Is this enough for pktgen to allocate the memory in that numa node? > Since the script only write

On 2020/7/17 ??1:16, Eugenio Perez Martin wrote: > On Fri, Jul 10, 2020 at 7:58 AM Michael S. Tsirkin <mst at redhat.com> wrote: >> On Fri, Jul 10, 2020 at 07:39:26AM +0200, Eugenio Perez Martin wrote: >>>>> How about playing with the batch size? Make it a mod parameter instead >>>>> of the hard coded 64, and measure for all values 1 to 64 ...

On Thu, Jul 16, 2020 at 07:16:27PM +0200, Eugenio Perez Martin wrote: > On Fri, Jul 10, 2020 at 7:58 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Fri, Jul 10, 2020 at 07:39:26AM +0200, Eugenio Perez Martin wrote: > > > > > How about playing with the batch size? Make it a mod parameter instead > > > > > of the hard coded 64, and

On Mon, Jun 22, 2020 at 06:11:21PM +0200, Eugenio Perez Martin wrote: > On Mon, Jun 22, 2020 at 5:55 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Fri, Jun 19, 2020 at 08:07:57PM +0200, Eugenio Perez Martin wrote: > > > On Mon, Jun 15, 2020 at 2:28 PM Eugenio Perez Martin > > > <eperezma at redhat.com> wrote: > > > > > >

...> > * This loop calls again fetch_buf, but vq->ndescs > 0 (and avail_vq == > > > > > > last_avail_vq), so it just return 1 > > > > > > > > > > That's what > > > > > [PATCH RFC v7 08/14] fixup! vhost: use batched get_vq_desc version > > > > > is supposed to fix. > > > > > > > > > > > > > Sorry, I forgot to include that fixup. > > > > > > > > With it I don't see CPU stalls, but with that version latency has > > > > increased a...

On Wed, Jun 10, 2020 at 04:29:29PM +0200, Eugenio P??rez wrote: > On Wed, 2020-06-10 at 07:36 -0400, Michael S. Tsirkin wrote: > > As testing shows no performance change, switch to that now. > > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > > Signed-off-by: Eugenio P??rez <eperezma at redhat.com> > > Link:

On 2020/6/11 ??7:34, Michael S. Tsirkin wrote: > static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq) > { > kfree(vq->descs); > @@ -394,6 +400,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev) > for (i = 0; i < dev->nvqs; ++i) { > vq = dev->vqs[i]; > vq->max_descs = dev->iov_limit; > + if

On 2020/6/11 ??7:34, Michael S. Tsirkin wrote: > static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq) > { > kfree(vq->descs); > @@ -394,6 +400,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev) > for (i = 0; i < dev->nvqs; ++i) { > vq = dev->vqs[i]; > vq->max_descs = dev->iov_limit; > + if