Re: [RFC PATCH] net: introduce HW Rate Limiting Driver API

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 10 May 2024 13:05:41 +0200 Paolo Abeni wrote:
> And the latter looks IMHO the simple/better. At that point I would
> probably drop the 'add' op and would rename 'delete' as
> 'reset':
> 
> int (*set)(struct net_device *dev, int how_many, const u32 *handles,
> 	   const struct net_shaper_info *shapers,
>            struct netlink_ext_ack *extack);
> int (*reset)(struct net_device *dev, int how_many, const u32 *handles,
>              struct netlink_ext_ack *extack);
> int (*move)(struct net_device *dev, int how_many, const u32 *handles,
>             const u32 *new_parent_handles,
> 	    struct netlink_ext_ack *extack);
> 
> An NIC with 'static' shapers can implement a dummy move always
> returning EOPNOTSUPP and eventually filling a detailed extack.
> 
> NIC without any constraints on mixing and matching different kind of
> shapers could implement the above as a loop over whatever they will do
> for the corresponding 'single shaper op'
> 
> NIC with constrains alike the one you pointed out could validate the
> final state before atomically applying the specified operation.
> 
> After a successful  'reset' operation, the kernel could drop any data
> it retains/caches for the relevant shapers - the current idea is to
> keep a copy of all successfully configured shaper_info in a xarray,
> using the 'handle' as the index.

IMHO this is more confusing that the current API, maybe we just need
better driver-facing documentation? Deleting a node from the hierarchy
doesn't delete the HW, same as deleting a TCAM entry doesn't chisel off
a part of the chip. If you want to switch from WRR to SP you'd need to
delete all the weight nodes and insert SP nodes as children.

If we modeled mux nodes as multi-entry nodes explicitly it may be
easier. Meaning make the scheduling and weights part of the mux node,
not its children.