On Mon, 5 Feb 2024 10:51:30 -0800 Joe Damato wrote: > > We reused the gro_flush_timeout as an existing "user doesn't care if > > packets get delayed by this much in worst case" value. If you set > > SO_PREFER_BUSY_POLL the next time you busy pool the NAPI will be marked > > as "already scheduled" and a timer is set (to gro_flush_timeout). > > If NIC IRQ fires before gro_flush_timeout it gets ignored, because NAPI > > is already marked as scheduled. > > If you busy poll again the timer gets postponed for another > > gro_flush_timeout nsec. > > If timer fires we go back to normal NAPI processing. > > Ah, I see. From my reading of the code in busy_poll_stop (which could be > wrong), defer_hard_irqs_count must also be non-zero to postpone the timer. > > Is that right? > > If so, I think the tricky thing with this is that these settings are > system-wide, so they'd affect non-busy poll apps, too. > > I think in the ideal case being able to set these on a per-NAPI basis would > be very helpful. Maybe something for me to try working on next. If wonder if it'd be good enough to do: min(defer_hard_irqs_count, 1) there. If caller asked to prefer busy poll they clearly want to poll. An explicit per-NAPI API works too, but it's a bit more work. If I was doing the work I'd try min(..., 1) with the workload. If there's value in having the full config - go for it.
