Re: [RFC PATCH net-next v2 0/6] net: xilinx: axienet: Enable adaptive IRQ coalescing with DIM

Nelson, Shannon
2024-09-10T01:34:15Z

On 9/9/2024 4:52 PM, Sean Anderson wrote:
>
> To improve performance without sacrificing latency under low load,
> enable DIM. While I appreciate not having to write the library myself, I
> do think there are many unusual aspects to DIM, as detailed in the last
> patch.
>
> This series depends on [1-2] and is therefore marked RFC. This series is
> otherwise ready to merge.
>
> [1] https://lore.kernel.org/netdev/20240909230908.1319982-1-sean.anderson@linux.dev/
> [2] https://lore.kernel.org/netdev/20240909231904.1322387-1-sean.anderson@linux.dev/
>
> Changes in v2:
> - Add some symbolic constants for IRQ delay timer
> - Report an error for bad coalesce settings
> - Don't use spin_lock_irqsave when we know the context
> - Split the CR calculation refactor from runtime coalesce settings
> adjustment support for easier review.
> - Have axienet_update_coalesce_rx/tx take the cr value/mask instead of
> calculating it with axienet_calc_cr. This will make it easier to add
> partial updates in the next few commits.
> - Get coalesce parameters from driver state
> - Don't take the RTNL in axienet_rx_dim_work to avoid deadlock. Instead,
> calculate a partial cr update that axienet_update_coalesce_rx can
> perform under a spin lock.
> - Use READ/WRITE_ONCE when accessing/modifying rx_irqs
>
> Sean Anderson (6):
> net: xilinx: axienet: Add some symbolic constants for IRQ delay timer
> net: xilinx: axienet: Report an error for bad coalesce settings
> net: xilinx: axienet: Combine CR calculation
> net: xilinx: axienet: Support adjusting coalesce settings while
> running
> net: xilinx: axienet: Get coalesce parameters from driver state
> net: xilinx: axienet: Enable adaptive IRQ coalescing with DIM
>
> drivers/net/ethernet/xilinx/Kconfig | 1 +
> drivers/net/ethernet/xilinx/xilinx_axienet.h | 31 +-
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 320 ++++++++++++++----
> 3 files changed, 273 insertions(+), 79 deletions(-)
>
> --
> 2.35.1.1320.gc452695387.dirty
>
>

Except for a couple of comment nits pointed out in 3/6 and 6/6, this set
seems reasonable.

Reviewed by: Shannon Nelson <shannon.nelson@amd.com>