netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@netronome.com>
To: Ido Schimmel <idosch@idosch.org>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Jiri Pirko <jiri@mellanox.com>,
	netdev@vger.kernel.org, oss-drivers@netronome.com,
	Baowen Zheng <baowen.zheng@corigine.com>,
	Louis Peens <louis.peens@netronome.com>
Subject: Re: [PATCH RFC net-next] net/sched: act_police: add support for packet-per-second policing
Date: Mon, 1 Feb 2021 13:31:17 +0100	[thread overview]
Message-ID: <20210201123116.GA25935@netronome.com> (raw)
In-Reply-To: <20210128161933.GA3285394@shredder.lan>

On Thu, Jan 28, 2021 at 06:19:33PM +0200, Ido Schimmel wrote:
> On Mon, Jan 25, 2021 at 04:18:19PM +0100, Simon Horman wrote:
> > From: Baowen Zheng <baowen.zheng@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.
> 
> 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.

Hi Ido,

sorry for missing this email until you pointed it out to me in another
thread.

We did consider this question during development and our conclusion was
that it was useful as we do have use-cases which call for both to be used
and it seems nice to allow lower layers to determine the order in which the
actions are applied to satisfied the user's more general request for both -
it should be no surprise that we plan to provide a hardware offload of this
feature. It also seems to offer nice code re-use. We did also try to
examine the performance impact of this change on existing use-cases and it
appeared to be negligible/within noise of our measurements.

> > 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 <baowen.zheng@corigine.com>
> > Signed-off-by: Simon Horman <simon.horman@netronome.com>
> > Signed-off-by: Louis Peens <louis.peens@netronome.com>
> > ---
> >  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.

  reply	other threads:[~2021-02-01 12:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25 15:18 [PATCH RFC net-next] net/sched: act_police: add support for packet-per-second policing Simon Horman
2021-01-27  2:38 ` Jakub Kicinski
2021-01-27 11:02   ` Simon Horman
2021-01-27 20:59     ` Jakub Kicinski
2021-01-28 12:02       ` Simon Horman
2021-01-28 12:08     ` Simon Horman
2021-01-28 16:19 ` Ido Schimmel
2021-02-01 12:31   ` Simon Horman [this message]
2021-02-01 12:38     ` Simon Horman
2021-02-01 17:41     ` Ido Schimmel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210201123116.GA25935@netronome.com \
    --to=simon.horman@netronome.com \
    --cc=baowen.zheng@corigine.com \
    --cc=idosch@idosch.org \
    --cc=jhs@mojatatu.com \
    --cc=jiri@mellanox.com \
    --cc=louis.peens@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).