On Tue, Nov 25, 2025 at 11:00:33AM -0700, Jon Kohler wrote: > In non-busypoll handle_rx paths, if peek_head_len returns 0, the RX > loop breaks, the RX wait queue is re-enabled, and vhost_net_signal_used > is called to flush done_idx and notify the guest if needed. > > However, signaling the guest can take non-trivial time. During this > window, additional RX payloads may arrive on rx_ring without further > kicks. These new payloads will sit unprocessed until another kick > arrives, increasing latency. In high-rate UDP RX workloads, this was > observed to occur over 20k times per second. > > To minimize this window and improve opportunities to process packets > promptly, immediately call peek_head_len after signaling. If new packets > are found, treat it as a busy poll interrupt and requeue handle_rx, > improving fairness to TX handlers and other pending CPU work. This also > helps suppress unnecessary thread wakeups, reducing waker CPU demand. > > Signed-off-by: Jon Kohler <[email protected]> > --- > drivers/vhost/net.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 35ded4330431..04cb5f1dc6e4 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -1015,6 +1015,27 @@ static int vhost_net_rx_peek_head_len(struct vhost_net > *net, struct sock *sk, > struct vhost_virtqueue *tvq = &tnvq->vq; > int len = peek_head_len(rnvq, sk); > > + if (!len && rnvq->done_idx) { > + /* When idle, flush signal first, which can take some > + * time for ring management and guest notification. > + * Afterwards, check one last time for work, as the ring > + * may have received new work during the notification > + * window. > + */ > + vhost_net_signal_used(rnvq, *count); > + *count = 0; > + if (peek_head_len(rnvq, sk)) { > + /* More work came in during the notification > + * window. To be fair to the TX handler and other > + * potentially pending work items, pretend like > + * this was a busy poll interruption so that > + * the RX handler will be rescheduled and try > + * again. > + */ > + *busyloop_intr = true; > + } > + } > + > if (!len && rvq->busyloop_timeout) { > /* Flush batched heads first */ > vhost_net_signal_used(rnvq, *count);
Looks like this can easily send more interrupts than originally? How can this be good? >From the description, I would expect the changes to just add another call to peek_head_len after the existing vhost_net_signal_used. What am I missing? > -- > 2.43.0
