[PATCH net-next 0/4] mpnic: add NAPI buffer depletion check

[Daniel Zahka <daniel.zahka@gmail.com>]

This series provides a buffer depletion check to unwedge Rx processing
when page pool allocations have failed. Patch 4 has a more detailed
description of the events that lead to the wedge, but the high level
idea is that when page pool allocations fail, the buffer descriptor ring
can run low, and when that happens the device will drop Rx packets and
not raise interrupts, which causes the NAPI event loop not to be
scheduled, so new buffers are not posted.

There are three setup patches for the depletion check:

Patch 1: convert writes to BDQ ring head and tail to WRITE_ONCE(), so
the depletion check, which is not synchronized with the NAPI event loop,
can READ_ONCE() those same fields.

Patch 2: introduce the driver level service task that runs once per
second while the netif is running.

Patch 3: set the minimum Rx buffers needed per packet based on page size
and max MTU.

With those in place, we have everything we need to watch the buffer ring
head and tail positions from the service task, compare posted buffers to
programmed Rx drop thresholds, and then force mpnic_poll() to run if
needed.

Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
---
Daniel Zahka (4):
      eth: mpnic: use WRITE_ONCE() for BDQ head and tail updates
      eth: mpnic: add a service task
      eth: mpnic: set Rx buffer minimums using page size and mtu
      eth: mpnic: add a NAPI depletion check

 drivers/net/ethernet/meta/mpnic/mpnic.h        |  3 +++
 drivers/net/ethernet/meta/mpnic/mpnic_init.c   | 13 ++++++---
 drivers/net/ethernet/meta/mpnic/mpnic_netdev.c |  3 +++
 drivers/net/ethernet/meta/mpnic/mpnic_pci.c    | 21 +++++++++++++++
 drivers/net/ethernet/meta/mpnic/mpnic_txrx.c   | 37 +++++++++++++++++++++++---
 drivers/net/ethernet/meta/mpnic/mpnic_txrx.h   |  7 +++++
 6 files changed, 77 insertions(+), 7 deletions(-)
---
base-commit: eb0c18404c8943356f4aa164e5db9067b79ea93c
change-id: 20260929-linux-mpnic-428998421ffc

Best regards,
-- 
Daniel Zahka <daniel.zahka@gmail.com>