On Fri, 27 Mar 2026 00:20:38 +0000 "Jasper Tran O'Leary" <[email protected]> wrote:
> In addition to application-initiated resets, during normal operation, > the device can indicate the need to reset by writing a value to a device > status register. This patch introduces an alarm that polls the > status of that register and informs the application of the need to > reset. The application is responsible for registering a callback that > will execute in the event that the alarm discovers that the device > requests a reset. > > Signed-off-by: Jasper Tran O'Leary <[email protected]> > Reviewed-by: Joshua Washington <[email protected]> Makes sense, AI analysis had one item worth noting. Not sure where documentation related (if any) should go. The alarm callback calls rte_eth_dev_callback_process() synchronously, which means the application's reset handler runs in the alarm thread context. The documentation example shows calling rte_eth_dev_reset() directly in the callback — this works (rte_eal_alarm_cancel from within a callback is allowed), but a production application would likely want to set a flag and handle the reset from the main thread. Worth a note in the doc example. The polling interval is 1 second vs 20 seconds in the kernel gve driver. Not wrong, but more aggressive — is there a reason for the shorter interval? Otherwise looks good. Applied to next-net
