On Mon, Aug 03, 2026 at 04:11:24PM +1000, David Gibson wrote:
On Fri, Jul 31, 2026 at 06:23:24PM +0200, Laurent Vivier wrote:
Move the static flow_timer_run variable out of flow.c and pass it as a parameter to flow_defer_handler(). This allows each caller to maintain its own timer state: each vhost-user queue pair worker uses the per-qpair context.
Signed-off-by: Laurent Vivier
One small misgiving about this, although I doubt it can cause a real problem. Becayse this timer processing now doesn't happen all at once, at each queue is on a separate timer cycle, it's theoretically possible for a flow to change qpair every FLOW_TIMER_INTERVAL and thereby indefinitely avoid having the timer running on it.
It's pretty tricky to do (depending on how close in real time each queue's timers end up running), and I don't *think* that can do anything terribly bad (maybe delay cleanup). But since the guest could in principle control the qpair placements to specifically trigger this, it just makes me think it warrants a good close look to make sure that something bad can't be triggered that way.
Looking at the next patch, I realised there's a much easier to hit concern here. Kind of the opposite of the one above, if there's a migration at the wrong moment, we might run the timer twice on a flow in a much smaller interval than usual. AFAICT, the worst that can do - at least with our current flow_defer() and flow_timer() functions is a little bit of unnecessary work, so I think it's ok. That's because none of them unconditionally do anything damaging - they always check an independent timestamp. However, it does add another wrinkle to what is and isn't safe in the defer and timer functions: they cannot rely on being called at most every INTERVAL seconds. We should probably document that... somewhere. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson