On Mon, Jan 25, 2021 at 04:18:19PM +0100, Simon Horman wrote:
> From: Baowen Zheng <[email protected]>
>
> Allow a policer action to enforce a rate-limit based on packets-per-second,
> configurable using a packet-per-second rate and burst parameters. This may
> be used in conjunction with existing byte-per-second rate limiting in the
> same policer action.
Hi Simon,
Any reason to allow metering based on both packets and bytes at the same
action versus adding a mode (packets / bytes) parameter? You can then
chain two policers if you need to rate limit based on both. Something
like:
# tc filter add dev tap1 ingress pref 1 matchall \
action police rate 1000Mbit burst 128k conform-exceed drop/pipe \
action police pkts_rate 3000 pkts_burst 1000
I'm asking because the policers in the Spectrum ASIC are built that way
and I also don't remember seeing such a mixed mode online.
>
> e.g.
> tc filter add dev tap1 parent ffff: u32 match \
> u32 0 0 police pkts_rate 3000 pkts_burst 1000
>
> Testing was unable to uncover a performance impact of this change on
> existing features.
>
> Signed-off-by: Baowen Zheng <[email protected]>
> Signed-off-by: Simon Horman <[email protected]>
> Signed-off-by: Louis Peens <[email protected]>
> ---
> include/net/sch_generic.h | 15 ++++++++++++++
> include/net/tc_act/tc_police.h | 4 ++++
> include/uapi/linux/pkt_cls.h | 2 ++
> net/sched/act_police.c | 37 +++++++++++++++++++++++++++++++---
> net/sched/sch_generic.c | 32 +++++++++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 3 deletions(-)
The intermediate representation in include/net/flow_offload.h needs to
carry the new configuration so that drivers will be able to veto
unsupported configuration.
