similar to: [PATCH] vhost-net: add time limitation for tx polling

On Tue, Apr 03, 2018 at 08:08:26AM +0000, haibinzhang(???) wrote: > handle_tx will delay rx for a long time when tx busy polling udp packets > with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > takes into account only sent-bytes but no single packet length. > > Tests were done between two Virtual Machines using netperf(UDP_STREAM, len=1), > then

On Tue, Apr 03, 2018 at 12:29:47PM +0000, haibinzhang(???) wrote: > > >On Tue, Apr 03, 2018 at 08:08:26AM +0000, haibinzhang wrote: > >> handle_tx will delay rx for a long time when tx busy polling udp packets > >> with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > >> takes into account only sent-bytes but no single packet length.

On Wed, Mar 28, 2018 at 02:37:04PM +0800, Jason Wang wrote: > > > On 2018?03?28? 12:01, haibinzhang(???) wrote: > > On 2018?03?27? 19:26, Jason wrote > > On 2018?03?27? 17:12, haibinzhang wrote: > > > > handle_tx() will delay rx for a long time when busy tx polling udp packets > > > > with short length(ie: 1byte udp payload), because setting

On 2018?03?28? 12:01, haibinzhang(???) wrote: > On 2018?03?27? 19:26, Jason wrote > On 2018?03?27? 17:12, haibinzhang wrote: >>> handle_tx() will delay rx for a long time when busy tx polling udp packets >>> with short length(ie: 1byte udp payload), because setting VHOST_NET_WEIGHT >>> takes into account only sent-bytes but no time. >> Interesting. >>

On 2018?03?28? 12:01, haibinzhang(???) wrote: > On 2018?03?27? 19:26, Jason wrote > On 2018?03?27? 17:12, haibinzhang wrote: >>> handle_tx() will delay rx for a long time when busy tx polling udp packets >>> with short length(ie: 1byte udp payload), because setting VHOST_NET_WEIGHT >>> takes into account only sent-bytes but no time. >> Interesting. >>

On Mon, Apr 09, 2018 at 04:09:20AM +0000, haibinzhang(???) wrote: > > > On Fri, Apr 06, 2018 at 08:22:37AM +0000, haibinzhang(???) wrote: > > > handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy > > > polling udp packets with small length(e.g. 1byte udp payload), because setting > > > VHOST_NET_WEIGHT takes into account only

On Fri, Apr 06, 2018 at 08:22:37AM +0000, haibinzhang(???) wrote: > handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy > polling udp packets with small length(e.g. 1byte udp payload), because setting > VHOST_NET_WEIGHT takes into account only sent-bytes but no single packet length. > > Ping-Latencies shown below were tested between two Virtual Machines

From: haibinzhang(???) <haibinzhang at tencent.com> Date: Fri, 6 Apr 2018 08:22:37 +0000 > handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy > polling udp packets with small length(e.g. 1byte udp payload), because setting > VHOST_NET_WEIGHT takes into account only sent-bytes but no single packet length. > > Ping-Latencies shown below were tested

From: haibinzhang(???) <haibinzhang at tencent.com> Date: Mon, 9 Apr 2018 07:22:17 +0000 > handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy > polling udp packets with small length(e.g. 1byte udp payload), because setting > VHOST_NET_WEIGHT takes into account only sent-bytes but no single packet length. > > Ping-Latencies shown below were tested

> @@ -461,6 +460,7 @@ static void handle_tx(struct vhost_net *net) > struct socket *sock; > struct vhost_net_ubuf_ref *uninitialized_var(ubufs); > bool zcopy, zcopy_used; > + int i, batched = VHOST_NET_BATCH; > > mutex_lock(&vq->mutex); > sock = vq->private_data; > @@ -475,6 +475,12 @@ static void handle_tx(struct

> @@ -461,6 +460,7 @@ static void handle_tx(struct vhost_net *net) > struct socket *sock; > struct vhost_net_ubuf_ref *uninitialized_var(ubufs); > bool zcopy, zcopy_used; > + int i, batched = VHOST_NET_BATCH; > > mutex_lock(&vq->mutex); > sock = vq->private_data; > @@ -475,6 +475,12 @@ static void handle_tx(struct

This patch implements basic batched processing of tx virtqueue by prefetching desc indices and updating used ring in a batch. For non-zerocopy case, vq->heads were used for storing the prefetched indices and updating used ring. It is also a requirement for doing more batching on top. For zerocopy case and for simplicity, batched processing were simply disabled by only fetching and processing

This patch tries to utilize tuntap rx batching by peeking the tx virtqueue during transmission, if there's more available buffers in the virtqueue, set MSG_MORE flag for a hint for backend (e.g tuntap) to batch the packets. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff

This patch tries to utilize tuntap rx batching by peeking the tx virtqueue during transmission, if there's more available buffers in the virtqueue, set MSG_MORE flag for a hint for backend (e.g tuntap) to batch the packets. Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 23 ++++++++++++++++++++---

On Fri, Sep 22, 2017 at 04:02:35PM +0800, Jason Wang wrote: > This patch implements basic batched processing of tx virtqueue by > prefetching desc indices and updating used ring in a batch. For > non-zerocopy case, vq->heads were used for storing the prefetched > indices and updating used ring. It is also a requirement for doing > more batching on top. For zerocopy case and for

On Fri, Sep 22, 2017 at 04:02:35PM +0800, Jason Wang wrote: > This patch implements basic batched processing of tx virtqueue by > prefetching desc indices and updating used ring in a batch. For > non-zerocopy case, vq->heads were used for storing the prefetched > indices and updating used ring. It is also a requirement for doing > more batching on top. For zerocopy case and for

On Mon, 21 May 2018 17:04:23 +0800 Jason wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/net.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 15d191a..de544ee 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -479,6

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 15d191a..de544ee 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -479,6 +479,12 @@ static size_t init_iov_iter(struct vhost_virtqueue *vq, struct iov_iter *iter, return

On Fri, Aug 15, 2014 at 11:40:08AM +0800, Jason Wang wrote: > After rx vq was enabled, we never stop polling its socket. This is sub optimal > when may lead unnecessary wake-ups after the rx net work has already been > queued. This could be optimized by stopping polling the rx net sock when > processing both rx and tx and restart it afterward. This could save unnecessary > wake-ups

Similar to commit a2ac99905f1e ("vhost-net: set packet weight of tx polling to 2 * vq size"), we need a packet-based limit for handler_rx, too - elsewhere, under rx flood with small packets, tx can be delayed for a very long time, even without busypolling. The pkt limit applied to handle_rx must be the same applied by handle_tx, or we will get unfair scheduling between rx and tx. Tying