similar to: [PATCH v2 net-next 0/4] vhost_net: Avoid vq kicks during busyloop

On 2018?07?03? 15:31, Toshiaki Makita wrote: > We may run out of avail rx ring descriptor under heavy load but busypoll > did not detect it so busypoll may have exited prematurely. Avoid this by > checking rx ring full during busypoll. Actually, we're checking whether it was empty in fact? > > Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> > ---

On 2018?07?03? 15:31, Toshiaki Makita wrote: > We may run out of avail rx ring descriptor under heavy load but busypoll > did not detect it so busypoll may have exited prematurely. Avoid this by > checking rx ring full during busypoll. Actually, we're checking whether it was empty in fact? > > Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> > ---

Under heavy load vhost busypoll may run without suppressing notification. For example tx zerocopy callback can push tx work while handle_tx() is running, then busyloop exits due to vhost_has_work() condition and enables notification but immediately reenters handle_tx() because the pushed work was tx. In this case handle_tx() tries to disable notification again, but when using event_idx it by

Under heavy load vhost busypoll may run without suppressing notification. For example tx zerocopy callback can push tx work while handle_tx() is running, then busyloop exits due to vhost_has_work() condition and enables notification but immediately reenters handle_tx() because the pushed work was tx. In this case handle_tx() tries to disable notification again, but when using event_idx it by

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive 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. v6->v7: fix issue and rebase codes: 1. on tx, busypoll will vhost_net_disable/enable_vq rx vq. [This is suggested by Toshiaki Makita

Hi Jason, On 2018/06/29 18:30, Jason Wang wrote: > On 2018?06?29? 16:09, Toshiaki Makita wrote: ... >> To fix this, poll the work instead of enabling notification when >> busypoll is interrupted by something. IMHO signal_pending() and >> vhost_has_work() are kind of interruptions rather than signals to >> completely cancel the busypoll, so let's run busypoll after

Hi Jason, On 2018/06/29 18:30, Jason Wang wrote: > On 2018?06?29? 16:09, Toshiaki Makita wrote: ... >> To fix this, poll the work instead of enabling notification when >> busypoll is interrupted by something. IMHO signal_pending() and >> vhost_has_work() are kind of interruptions rather than signals to >> completely cancel the busypoll, so let's run busypoll after

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

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive 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, 5, 6 Tonghao Zhang (6): net: vhost: lock the vqs one by one net: vhost: replace magic number of lock annotation net: vhost: factor out

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive 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, 5, 6 Tonghao Zhang (6): net: vhost: lock the vqs one by one net: vhost: replace magic number of lock annotation net: vhost: factor out

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive 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. v5->v6: rebase the codes. Tonghao Zhang (4): net: vhost: lock the vqs one by one net: vhost: replace magic number of lock annotation

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> This patches improve the guest receive 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 Tonghao Zhang (4): net: vhost: lock the vqs one by one net: vhost: replace magic number of lock annotation net: vhost: factor out busy

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:

On 2018/08/03 12:24, Tonghao Zhang wrote: > On Fri, Aug 3, 2018 at 11:07 AM Jason Wang <jasowang at redhat.com> wrote: >> On 2018?08?03? 10:51, Tonghao Zhang wrote: >>> On Thu, Aug 2, 2018 at 5:23 PM Jason Wang <jasowang at redhat.com> wrote: >>>> On 2018?08?02? 16:41, Toshiaki Makita wrote: >>>>> On 2018/08/02 17:18, Jason Wang wrote:

On 2018/08/03 12:24, Tonghao Zhang wrote: > On Fri, Aug 3, 2018 at 11:07 AM Jason Wang <jasowang at redhat.com> wrote: >> On 2018?08?03? 10:51, Tonghao Zhang wrote: >>> On Thu, Aug 2, 2018 at 5:23 PM Jason Wang <jasowang at redhat.com> wrote: >>>> On 2018?08?02? 16:41, Toshiaki Makita wrote: >>>>> On 2018/08/02 17:18, Jason Wang wrote:

On 2018/07/02 15:17, Jason Wang wrote: > On 2018?07?02? 12:37, Toshiaki Makita wrote: >> On 2018/07/02 11:54, Jason Wang wrote: >>> On 2018?07?02? 10:45, Toshiaki Makita wrote: >>>> Hi Jason, >>>> >>>> On 2018/06/29 18:30, Jason Wang wrote: >>>>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >>>> ...

On 2018/07/02 15:17, Jason Wang wrote: > On 2018?07?02? 12:37, Toshiaki Makita wrote: >> On 2018/07/02 11:54, Jason Wang wrote: >>> On 2018?07?02? 10:45, Toshiaki Makita wrote: >>>> Hi Jason, >>>> >>>> On 2018/06/29 18:30, Jason Wang wrote: >>>>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >>>> ...

On 2018/07/02 11:54, Jason Wang wrote: > On 2018?07?02? 10:45, Toshiaki Makita wrote: >> Hi Jason, >> >> On 2018/06/29 18:30, Jason Wang wrote: >>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >> ... >>>> To fix this, poll the work instead of enabling notification when >>>> busypoll is interrupted by something. IMHO signal_pending() and