[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201116233027.GC1756591@lunn.ch>
Date: Tue, 17 Nov 2020 00:30:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Grygorii Strashko <grygorii.strashko@...com>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>,
Vignesh Raghavendra <vigneshr@...com>,
Sekhar Nori <nsekhar@...com>, linux-kernel@...r.kernel.org,
linux-omap@...r.kernel.org, Tony Lindgren <tony@...mide.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH net-next 3/3] net: ethernet: ti: am65-cpsw: enable
broadcast/multicast rate limit support
> Same as above, just in packets per second.
>
> tc qdisc add dev eth0 clsact
> tc filter add dev eth0 ingress flower skip_sw \
> dst_mac 01:00:00:00:00:00/01:00:00:00:00:00 \
> action police rate 20kpps
I agree with Vladimir here. Since the hardware does PPS limits, the TC
API should also be PPS limit based. And as you said, CPU load is more
a factor of PPS than BPS, so it is a useful feature in general to
have. You just need to implement the software version first, before
you offload it to the hardware.
Andrew
Powered by blists - more mailing lists