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

[Simon Horman <horms@kernel.org>]

On Wed, May 15, 2024 at 04:19:57PM +0200, Andrew Lunn wrote:
> > > If I read correctly, allowing each NIC to expose it's own different
> > > starting configuration still will not solve the problem for this H/W to
> > > switch from WRR to SP (and vice versa).
> 
> I also suspect this is not unique to this hardware. I've not looked at
> other SOHO switches, but it is reasonably common to have different
> queues for different priority classes, and then one shaper for the
> overall port rate.

Yes, understood. It's about creating a sufficiently general solution.
And the HW you have in mind has lead us to see some shortcomings
of the proposed API in that area. Because it drew a bit too much on
understanding of a different category of HW.

> > > AFAICS, what would be needed there is an atomic set of operations:
> > > 'set_many' (and e.v. 'delete_many', 'create_many') that will allow
> > > changing all the shapers at once. 
> 
> Yep.
> 
> > > With such operations, that H/W could still fit the expected 'no-op'
> > > default, as WRR on the queue shapers is what we expect. I agree with
> > > Jakub, handling the complexity of arbitrary starting configuration
> > > would pose a lot of trouble to the user/admin.
> > > 
> > > If all the above stands together, I think we have a few options (in
> > > random order):
> > > 
> > > - add both set of operations: the ones operating on a single shaper and
> > > the ones operating on multiple shapers
> > > - use only the multiple shapers ops.
> > > 
> > > And the latter looks IMHO the simple/better.
> 
> I would agree, start with only multiple shaper opps. If we find that
> many implementation end up just iterating the list and dealing with
> them individually, would could pull that iterator into the core, and
> expand the ops to either/or, multiple or single.

FWIIW, this was my thinking too.

> > > 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.
> 
> The extack is going to be important here, we are going to need
> meaningful error messages.

Always :)

> Overall, i think this can be made to work with the hardware i have.

Great, I think the next step is for us to propose a revised API
with multiple shaper ops in place of single shaper ops.