netdev - RE: 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: 
 <BY3PR18MB4737760F45BAFC010FAE3680C6112@BY3PR18MB4737.namprd18.prod.outlook.com>
Date: Tue, 23 Apr 2024 15:56:22 +0000
From: Sunil Kovvuri Goutham <sgoutham@...vell.com>
To: Paolo Abeni <pabeni@...hat.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: Re: [RFC] HW TX Rate Limiting Driver API



> -----Original Message-----
> From: Paolo Abeni <pabeni@...hat.com>
> Sent: Tuesday, April 23, 2024 7:38 PM
> To: Sunil Kovvuri Goutham <sgoutham@...vell.com>; Simon Horman
> <horms@...nel.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: [EXTERNAL] 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.

Thanks for the clarification.

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


Makes sense and agree.

Thanks,
Sunil.