similar to: [PATCH] vhost-net: add limitation of sent packets 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 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

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. Looking at vhost_can_busy_poll() it tries to poke pending vhost work and exit the busy loop if it found one. So I believe

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

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

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

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

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

We used to have vhost_exceeds_weight() for vhost-net to: - prevent vhost kthread from hogging the cpu - balance the time spent between TX and RX This function could be useful for vsock and scsi as well. So move it to vhost.c. Device must specify a weight which counts the number of requests, or it can also specific a byte_weight which counts the number of bytes that has been processed.

On Mon, 21 May 2018 17:04:24 +0800 Jason wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/net.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index de544ee..4ebac76 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -485,6

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index de544ee..4ebac76 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -485,6 +485,13 @@ static bool vhost_exceeds_weight(int pkts, int total_len) unlikely(pkts >=

vDPA device currently relays the eventfd via vhost worker. This is inefficient due the latency of wakeup and scheduling, so this patch tries to introduce a use_worker attribute for the vhost device. When use_worker is not set with vhost_dev_init(), vhost won't try to allocate a worker thread and the vhost_poll will be processed directly in the wakeup function. This help for vDPA since it

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

Hi: This series implement batch updating of used ring for TX. This help to reduce the cache contention on used ring. The idea is first split datacopy path from zerocopy, and do only batching for datacopy. This is because zercopy had already supported its own batching. TX PPS was increased 25.8% and Netperf TCP does not show obvious differences. The split of datapath will also be helpful for

Hi: This series implement batch updating of used ring for TX. This help to reduce the cache contention on used ring. The idea is first split datacopy path from zerocopy, and do only batching for datacopy. This is because zercopy had already supported its own batching. TX PPS was increased 25.8% and Netperf TCP does not show obvious differences. The split of datapath will also be helpful for

Instead of mixing zerocopy and datacopy logics, this patch tries to split datacopy logic out. This results for a more compact code and specific optimization could be done on top more easily. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 102 insertions(+), 9 deletions(-) diff --git