On Tue, 24 Nov 2020 11:22:03 +0800 Jason Wang wrote:

quoted

quoted

Perhaps you need the trylock in virtnet_poll_tx()?  

That could work. Best if we used normal lock if !!budget, and trylock
when budget is 0. But maybe that's too hairy.  

If we use trylock, we probably lose(or delay) tx notification that may 
have side effects to the stack.

That's why I said only trylock with budget == 0. Only netpoll calls with
budget == 0, AFAIK.

quoted

I'm assuming all this trickiness comes from virtqueue_get_buf() needing
locking vs the TX path? It's pretty unusual for the completion path to
need locking vs xmit path.  

Two reasons for doing this:

1) For some historical reason, we try to free transmitted tx packets in 
xmit (see free_old_xmit_skbs() in start_xmit()), we can probably remove 
this if we remove the non tx interrupt mode.
2) virtio core requires virtqueue_get_buf() to be synchronized with 
virtqueue_add(), we probably can solve this but it requires some non 
trivial refactoring in the virtio core

Btw, have a quick search, there are several other drivers that uses tx 
lock in the tx NAPI.

Unless they do:

	netdev->priv_flags |= IFF_DISABLE_NETPOLL;

they are all broken.