Re: [PATCH net v3 1/2] bnge: cap RSS contexts and RX rings to the RSS table size
From: Simon Horman
Date: Wed Oct 28 2026 - 09:58:16 EST
On Mon, Oct 26, 2026 at 02:57:56PM +0530, Vikas Gupta wrote:
> From: Dharmender Garg <dharmender.garg@xxxxxxxxxxxx>
>
> The hardware supports at most BNGE_RSS_TABLE_MAX_TBL (8) RSS contexts.
> They are stored in vnic->fw_rss_cos_lb_ctx[8] and back a 512-entry
> (BNGE_MAX_RSS_TABLE_ENTRIES) indirection table and DMA buffer, so at
> most 512 RX rings can be served by RSS.
>
> bnge_cal_nr_rss_ctxs() has no upper bound, so with more RX rings it
> returns more than 8 contexts: bnge_setup_vnic() writes past
> fw_rss_cos_lb_ctx[], bnge_set_dflt_rss_indir_tbl() and
> bnge_fill_hw_rss_tbl() write past the indirection table and its DMA
> buffer, and the pad computation in bnge_set_dflt_rss_indir_tbl()
> underflows into a huge memset().
>
> Cap the number of contexts at BNGE_RSS_TABLE_MAX_TBL and the number
> of RX rings at BNGE_MAX_RSS_TABLE_ENTRIES, so the sizes derived from
> the ring count always fit the arrays.
>
> Fixes: 627c67f038d2 ("bng_en: Add resource management support")
> Signed-off-by: Dharmender Garg <dharmender.garg@xxxxxxxxxxxx>
> Reviewed-by: Vikas Gupta <vikas.gupta@xxxxxxxxxxxx>
> ---
> drivers/net/ethernet/broadcom/bnge/bnge_resc.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_resc.c b/drivers/net/ethernet/broadcom/bnge/bnge_resc.c
> index 4711dd4945ff..b540eed12fc6 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge_resc.c
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge_resc.c
> @@ -182,8 +182,9 @@ int bnge_cal_nr_rss_ctxs(u16 rx_rings)
> if (!rx_rings)
> return 0;
>
> - return bnge_adjust_pow_two(rx_rings - 1,
> - BNGE_RSS_TABLE_ENTRIES);
> + return min_t(int, bnge_adjust_pow_two(rx_rings - 1,
> + BNGE_RSS_TABLE_ENTRIES),
> + BNGE_RSS_TABLE_MAX_TBL);
> }
nit: I expect that min() is sufficient here as the return value of
bnge_adjust_pow_two is unsigned and BNGE_RSS_TABLE_MAX_TBL
is a non-negative constant.
That notwithstanding this looks good to me.
Reviewed-by: Simon Horman <horms@xxxxxxxxxx>
...