lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <79767d80-4f9c-4eec-8e9d-32ea94d0e06a@lunn.ch>
Date: Wed, 15 May 2024 16:19:57 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Simon Horman <horms@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
	Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>,
	Madhu Chittim <madhu.chittim@...el.com>,
	Sridhar Samudrala <sridhar.samudrala@...el.com>,
	John Fastabend <john.fastabend@...il.com>,
	Sunil Kovvuri Goutham <sgoutham@...vell.com>,
	Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [RFC PATCH] net: introduce HW Rate Limiting Driver API

> > 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.

> > 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.

> > 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.

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

	 Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ