Subject: Re: [PATCH net-next 04/11] eth: bnxt: move from .set_rxfh to .create_rxfh_context and friends

From: Edward Cree <[email-masked]>
Date: Wed, 3 Jul 2024 13:06:13 +0100

On 03/07/2024 00:47, Jakub Kicinski wrote:
> Use the new ethtool ops for RSS context management. The conversion
> is pretty straightforward cut / paste of the right chunks of the
> combined handler. Main change is that we let the core pick the IDs
> (bitmap will be removed separately for ease of review), so we need
> to tell the core when we lose a context.
> Since the new API passes rxfh as const, change bnxt_modify_rss()
> to also take const.
> 
> Signed-off-by: Jakub Kicinski <[email-masked]>
...
> @@ -5271,6 +5296,7 @@ void bnxt_ethtool_free(struct bnxt *bp)
>  const struct ethtool_ops bnxt_ethtool_ops = {
>  	.cap_link_lanes_supported	= 1,
>  	.cap_rss_ctx_supported		= 1,
> +	.rxfh_max_context_id		= BNXT_MAX_ETH_RSS_CTX,

According to Pavan [1], this limit only existed for the sake of the
 SW side (presumably the rss_ctx_bmap), so probably it can be removed
 in patch #5.
The higher FW limit Pavan mentions appears to be on number rather
 than index; at least I can't see anything in the driver feeding the
 user-facing context ID to the device.  But I don't know whether FW
 has any opportunity to say ENOMEM, or whether the driver needs to
 validate against the hardware limit itself.  Hopefully Pavan (CCed)
 can elaborate.

-ed

[1] https://lore.kernel.org/netdev/CALs4sv2dyy3uy+Xznm41M3uOkv1TSoGMwVBL5Cwzv=_E=[email-masked]/