similar to: [PATCH net-next v2] net: vhost: improve performance when enable busyloop

On Wed, Jun 27, 2018 at 10:24:43PM +0800, Jason Wang wrote: > > > On 2018?06?26? 13:17, xiangxia.m.yue at gmail.com wrote: > > From: Tonghao Zhang <xiangxia.m.yue at gmail.com> > > > > This patch improves the guest receive performance from > > host. On the handle_tx side, we poll the sock receive > > queue at the same time. handle_rx do that in the

On 2018?06?30? 14:33, xiangxia.m.yue at gmail.com wrote: > From: Tonghao Zhang <xiangxia.m.yue at gmail.com> > > Factor out generic busy polling logic and will be > used for tx path in the next patch. And with the patch, > qemu can set differently the busyloop_timeout for rx queue. > > Signed-off-by: Tonghao Zhang <zhangtonghao at didichuxing.com> > --- >

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive and transmit performance. On the handle_tx side, we poll the sock receive queue at the same time. handle_rx do that in the same way. This patches are splited from previous big patch: http://patchwork.ozlabs.org/patch/934673/ For more performance report, see patch 4. Tonghao Zhang (4): net: vhost:

This patch improves the guest receive performance from host. On the handle_tx side, we poll the sock receive queue at the same time. handle_rx do that in the same way. we set the poll-us=100 us and use the iperf3 to test its throughput. The iperf3 command is shown as below. iperf3 -s -D iperf3 -c 192.168.1.100 -i 1 -P 10 -t 10 -M 1400 --bandwidth 100000M * With the patch: 21.1 Gbits/sec *

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> Factor out generic busy polling logic and will be used for tx path in the next patch. And with the patch, qemu can set differently the busyloop_timeout for rx queue. Signed-off-by: Tonghao Zhang <zhangtonghao at didichuxing.com> --- drivers/vhost/net.c | 92 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 53

On 2018?07?02? 20:57, xiangxia.m.yue at gmail.com wrote: > From: Tonghao Zhang <xiangxia.m.yue at gmail.com> > > Factor out generic busy polling logic and will be > used for in tx path in the next patch. And with the patch, > qemu can set differently the busyloop_timeout for rx queue. > > Signed-off-by: Tonghao Zhang <zhangtonghao at didichuxing.com> > --- >

On 2018?07?02? 20:57, xiangxia.m.yue at gmail.com wrote: > From: Tonghao Zhang <xiangxia.m.yue at gmail.com> > > Factor out generic busy polling logic and will be > used for in tx path in the next patch. And with the patch, > qemu can set differently the busyloop_timeout for rx queue. > > Signed-off-by: Tonghao Zhang <zhangtonghao at didichuxing.com> > --- >

On 2018?07?03? 13:48, Tonghao Zhang wrote: > On Tue, Jul 3, 2018 at 10:12 AM Jason Wang <jasowang at redhat.com> wrote: >> >> >> On 2018?07?02? 20:57, xiangxia.m.yue at gmail.com wrote: >>> From: Tonghao Zhang <xiangxia.m.yue at gmail.com> >>> >>> Factor out generic busy polling logic and will be >>> used for in tx path in the

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive and transmit performance. On the handle_tx side, we poll the sock receive queue at the same time. handle_rx do that in the same way. For more performance report, see patch 4. v4 -> v5: fix some issues v3 -> v4: fix some issues v2 -> v3: This patches are splited from previous big patch:

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive and transmit performance. On the handle_tx side, we poll the sock receive queue at the same time. handle_rx do that in the same way. For more performance report, see patch 4. v4 -> v5: fix some issues v3 -> v4: fix some issues v2 -> v3: This patches are splited from previous big patch:

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive and transmit performance. On the handle_tx side, we poll the sock receive queue at the same time. handle_rx do that in the same way. For more performance report, see patch 4. v3 -> v4: fix some issues v2 -> v3: This patches are splited from previous big patch:

On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote: > When we try to do rx busy polling in tx path in commit 441abde4cd84 > ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex > after tx vq mutex is held. This may lead deadlock so we try to lock vq > one by one in commit 78139c94dc8c ("net: vhost: lock the vqs one by > one"). With this

On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote: > When we try to do rx busy polling in tx path in commit 441abde4cd84 > ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex > after tx vq mutex is held. This may lead deadlock so we try to lock vq > one by one in commit 78139c94dc8c ("net: vhost: lock the vqs one by > one"). With this

On 2018?08?01? 11:00, xiangxia.m.yue at gmail.com wrote: > From: Tonghao Zhang <xiangxia.m.yue at gmail.com> > > Factor out generic busy polling logic and will be > used for in tx path in the next patch. And with the patch, > qemu can set differently the busyloop_timeout for rx queue. > > In the handle_tx, the busypoll will vhost_net_disable/enable_vq > because we

On 2018?08?01? 11:00, xiangxia.m.yue at gmail.com wrote: > From: Tonghao Zhang <xiangxia.m.yue at gmail.com> > > Factor out generic busy polling logic and will be > used for in tx path in the next patch. And with the patch, > qemu can set differently the busyloop_timeout for rx queue. > > In the handle_tx, the busypoll will vhost_net_disable/enable_vq > because we

On Tue, Dec 11, 2018 at 11:06:43AM +0800, Jason Wang wrote: > > On 2018/12/11 ??9:34, Michael S. Tsirkin wrote: > > On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote: > > > When we try to do rx busy polling in tx path in commit 441abde4cd84 > > > ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex > > > after tx vq mutex is

On Tue, Dec 11, 2018 at 11:06:43AM +0800, Jason Wang wrote: > > On 2018/12/11 ??9:34, Michael S. Tsirkin wrote: > > On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote: > > > When we try to do rx busy polling in tx path in commit 441abde4cd84 > > > ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex > > > after tx vq mutex is

When we try to do rx busy polling in tx path in commit 441abde4cd84 ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex after tx vq mutex is held. This may lead deadlock so we try to lock vq one by one in commit 78139c94dc8c ("net: vhost: lock the vqs one by one"). With this commit, we avoid the deadlock with the assumption that handle_rx() and handle_tx() run

On 2018/12/11 ??9:34, Michael S. Tsirkin wrote: > On Mon, Dec 10, 2018 at 05:44:52PM +0800, Jason Wang wrote: >> When we try to do rx busy polling in tx path in commit 441abde4cd84 >> ("net: vhost: add rx busy polling in tx path"), we lock rx vq mutex >> after tx vq mutex is held. This may lead deadlock so we try to lock vq >> one by one in commit 78139c94dc8c

On Tue, Jul 3, 2018 at 10:12 AM Jason Wang <jasowang at redhat.com> wrote: > > > > On 2018?07?02? 20:57, xiangxia.m.yue at gmail.com wrote: > > From: Tonghao Zhang <xiangxia.m.yue at gmail.com> > > > > Factor out generic busy polling logic and will be > > used for in tx path in the next patch. And with the patch, > > qemu can set differently