Re: [RFC PATCH v2 net-next 6/7] net: ethtool: add a mutex protecting RSS contexts

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

On 13/04/2023 22:58, Andrew Lunn wrote:
>> (Idk, maybe sfc is just uniquely complex and messy.  It wouldn't be
>>  the first time.)
> 
> Hi Ed
> 
> Have you looked at other drivers? It would be bad to design an API
> around a messy driver.

I have; there's really not many that implement custom RSS contexts
 (just Marvell's mvpp2 and octeontx2, and Mellanox's mlx5).  The
 `rss_ctx_max_id` field is designed for those as they all have fixed-
 size arrays currently and idk whether that's a purely software limit
 or whether it reflects the hardware.
I couldn't find anything in any of them that looked like "restore
 stuff after a device reboot"; maybe it's just not something those
 devices expect to experience normally.

I don't know enough about mlx5 hw to really understand their filter
 code, but the rough equivalent of our efx_mcdi_filter_insert_locked()
 in that driver appears to be _mlx5_add_flow_rules(), which seems to
 be doing some kind of hand-over-hand locking.  And no sign (whether
 in comments or in asserts) of whether the function expects callers to
 hold RTNL.  Same goes for their functions operating on TIRs (whatever
 those are) which are called from all over (aRFS, tc, even kTLS!) in
 addition to the ethtool RSS/ntuple paths.

Anyway I'll cc maintainers of those drivers on v3 so they can chime
 in on the API design.  (Should've done that on v1 really, but I
 forgot.  Mea culpa.)

-ed