netdev - Re: [RFC] HW TX Rate Limiting Driver API

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: <64ebeda4a6f7b95adcce533d4ce9a657535ba0c4.camel@redhat.com>
Date: Tue, 23 Apr 2024 16:07:48 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Sunil Kovvuri Goutham <sgoutham@...vell.com>, Simon Horman
	 <horms@...nel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc: Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>, Madhu
 Chittim <madhu.chittim@...el.com>, Sridhar Samudrala
 <sridhar.samudrala@...el.com>
Subject: Re: [RFC] HW TX Rate Limiting Driver API

On Mon, 2024-04-22 at 11:30 +0000, Sunil Kovvuri Goutham wrote:
> 
> On Friday, April 5, 2024 3:53 PM Simon Horman <horms@...nel.org> wrote:
[...]
> > /**
> >  * struct shaper_info - represent a node of the shaper hierarchy
> >  * @id: Unique identifier inside the shaper tree.
> >  * @parent_id: ID of parent shaper, or SHAPER_NONE_ID if the shaper has
> >  *             no parent. Only the root shaper has no parent.
> >  * @metric: Specify if the bw limits refers to PPS or BPS
> >  * @bw_min: Minimum guaranteed rate for this shaper
> >  * @bw_max: Maximum peak bw allowed for this shaper
> >  * @burst: Maximum burst for the peek rate of this shaper
> >  * @priority: Scheduling priority for this shaper
> >  * @weight: Scheduling weight for this shaper
> >  *
> >  * The full shaper hierarchy is maintained only by the
> >  * NIC driver (or firmware), possibly in a NIC-specific format
> >  * and/or in H/W tables.
> >  * The kernel uses this representation and the shaper_ops to
> >  * access, traverse, and update it.
> >  */
> > struct shaper_info {
> > 	/* The following fields allow the full traversal of the whole
> > 	 * hierarchy.
> > 	 */
> > 	u32 id;
> > 	u32 parent_id;
> > 
> > 	/* The following fields define the behavior of the shaper. */
> > 	enum shaper_metric metric;
> > 	u64 bw_min;
> > 	u64 bw_max;
> > 	u32 burst;
> > 	u32 priority;
> > 	u32 weight;
> > };
> > 
> 
> 'bw_min/max' is u64 and 'burst' / 'weight' are u32, any specific reason ?

A NIC can exceed UINT32_MAX bps, while UINT32_MAX different values look
more then enough to cope for different weights.

No strong opinions, we can increase the weight range, but it looks a
bit overkill to me.

[...]
> Can you please confirm below
> 1. Does privileged VF mean trusted VF ?

Yes. But keep in mind that given the current status of discussion we
are going to drop privileged/trusted VF reference.

> 2. With this we can setup below as well, from PF ?
>      -- Per-VF Quantum
>      -- Per-VF Strict priority
>      -- Per-VF ratelimit

Assuming the NIC H/W support it, yes: the host will have full control
over all the available shaper.

> 3. Wondering if it would be beneficial to apply this to ingress traffic as well, all modes may or may not apply,
>      but at the least it could be possible to apply PPS/BPS ratelimit. So that the configuration methodology
>      remains same across egress and ingress.

I think the API could be extended to the RX side, too, as a follow-
up/next step. This relatively simple feature is in progress since a
significant time, I think it would be nice try to have it in place
first.

We will try to ensure there will be no naming clash for such extension.

Cheers,

Paolo