On Fri, Jan 29, 2021 at 09:30:00AM -0500, Jamal Hadi Salim wrote: > On 2021-01-29 5:28 a.m., Simon Horman wrote: > > From: Baowen Zheng <baowen.zh...@corigine.com> > > > > 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. > > > > 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. > > > > Ido's comment is important: Why not make packet rate vs byte rate > mutually exclusive? If someone uses packet rate then you make sure > they dont interleave with attributes for byte rate and vice-versa. > > I dont see featurewise impact - but certainly the extra check > in the fastpath will likely have a small performance impact > at high rates. Probably not a big deal (if Eric D. is not looking). > Side note: this policer (with your addition) is now supporting 3 policer > algorithms - i wonder if it makes sense to start spliting the different > policers (which will solve the performance impact).
Sorry, I somehow missed Ido's email until you and he pointed it out in this thread. Regarding splitting up the policer action. I think there is some value to the current setup in terms of code re-use and allowing combinations of features. But I do agree it would be a conversation worth having at some point.
