[<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.
Powered by blists - more mailing lists