On 2018年06月30日 00:38, Michael S. Tsirkin wrote:
On Fri, Jun 29, 2018 at 05:09:50PM +0900, Toshiaki Makita wrote:
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 design
cannot. Then busyloop will run without suppressing notification.
Another example is the case where handle_tx() tries to enable
notification but avail idx is advanced so disables it again. This case
also lead to the same situation with event_idx.
The problem is that once we enter this situation busyloop does not work
under heavy load for considerable amount of time, because notification
is likely to happen during busyloop and handle_tx() immediately enables
notification after notification happens. Specifically busyloop detects
notification by vhost_has_work() and then handle_tx() calls
vhost_enable_notify().
I'd like to understand the problem a bit better.
Why does this happen?
Doesn't this only happen if ring is empty?
My understanding is:
vhost_zerocopy_callback() try to poll vhost virtqueue. This will cause
the busy loop in vhost_net_tx_get_vq_desc() to exit because of
vhost_has_work() return true. Then handle_tx() tends to enable
notification. Then guest may kick us even if handle_tx() call
vhost_disable_notify() which in fact did nothing for even index.
Maybe we can try to call vhost_zerocopy_signal_used() if we found
there's pending used from zerocopy instead.
Thanks
