On 12/24/25 23:49, Bui Quang Minh wrote:
On 12/24/25 08:47, Michael S. Tsirkin wrote:
On Wed, Dec 24, 2025 at 09:37:14AM +0800, Xuan Zhuo wrote:
Hi Jason,
I'm wondering why we even need this refill work. Why not simply let
NAPI retry
the refill on its next run if the refill fails? That would seem much
simpler.
This refill work complicates maintenance and often introduces a lot of
concurrency issues and races.
Thanks.
refill work can refill from GFP_KERNEL, napi only from ATOMIC.
And if GFP_ATOMIC failed, aggressively retrying might not be a great
idea.
Not saying refill work is a great hack, but that is the reason for it.
In case no allocated received buffer and NAPI refill fails, the host
will not send any packets. If there is no busy polling loop either,
the RX will be stuck. That's also the reason why we need refill work.
Is it correct?
I've just looked at mlx5e_napi_poll which is mentioned by Jason. So if
we want to retry refilling in the next NAPI, we can set a bool (e.g.
retry_refill) in virtnet_receive, then in virtnet_poll, we don't call
virtqueue_napi_complete. As a result, our napi poll is still in the
softirq's poll list, so we don't need a new host packet to trigger
virtqueue's callback which calls napi_schedule again.
Thanks,
Quang Minh.
