[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230612185110.bppazw2mgbyoj6nz@skbuf>
Date: Mon, 12 Jun 2023 21:51:10 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc: Alexis Lothoré <alexis.lothore@...tlin.com>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
paul.arola@...us.com, scott.roberts@...us.com
Subject: Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: implement egress tbf
qdisc for 6393x family
On Mon, Jun 12, 2023 at 11:53:06PM +0530, Sunil Kovvuri wrote:
> On Mon, Jun 12, 2023 at 3:13 PM Vladimir Oltean <olteanv@...il.com> wrote:
> >
> > Hi Sunil,
> >
> > On Mon, Jun 12, 2023 at 12:04:56PM +0530, Sunil Kovvuri wrote:
> > > For setting up simple per-port ratelimit, instead of TBF isn't "egress
> > > matchall" suitable here ?
> >
> > "matchall" is a filter. What would be the associated action for a
> > port-level shaper?
>
> As Alexis mentioned I was referring to "matchall + policer".
The idea would be to pick a software representation which matches the
hardware behavior. A policer drops excess packets, a shaper queues them.
This hardware supports some sort of egress rate shaping.
Powered by blists - more mailing lists