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

[Edward Cree <ecree.xilinx@gmail.com>]

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 <kuba@kernel.org>
...
> @@ -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=+L_4A@mail.gmail.com/