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: David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, oss-drivers@netronome.com,
	Xingfeng Hu <xingfeng.hu@corigine.com>,
	Baowen Zheng <baowen.zheng@corigine.com>,
	Louis Peens <louis.peens@netronome.com>
Subject: Re: [PATCH v3 net-next 0/3] net/sched: act_police: add support for packet-per-second policing
Date: Mon, 15 Mar 2021 15:41:56 +0100	[thread overview]
Message-ID: <20210315144155.GA2053@netronome.com> (raw)
In-Reply-To: <YE3GofZN1jAeOyFV@shredder.lan>

On Sun, Mar 14, 2021 at 10:17:37AM +0200, Ido Schimmel wrote:
> On Fri, Mar 12, 2021 at 03:08:28PM +0100, Simon Horman wrote:
> > This series enhances the TC policer action implementation to allow a
> > policer action instance to enforce a rate-limit based on
> > packets-per-second, configurable using a packet-per-second rate and burst
> > parameters.
> > 
> > In the hope of aiding review this is broken up into three patches.
> > 
> > * [PATCH 1/3] flow_offload: add support for packet-per-second policing
> > 
> >   Add support for this feature to the flow_offload API that is used to allow
> >   programming flows, including TC rules and their actions, into hardware.
> > 
> > * [PATCH 2/3] flow_offload: reject configuration of packet-per-second policing in offload drivers
> > 
> >   Teach all exiting users of the flow_offload API that allow offload of
> >   policer action instances to reject offload if packet-per-second rate
> >   limiting is configured: none support it at this time
> > 
> > * [PATCH 3/3] net/sched: act_police: add support for packet-per-second policing
> > 
> >   With the above ground-work in place add the new feature to the TC policer
> >   action itself
> > 
> > With the above in place the feature may be used.
> > 
> > As follow-ups we plan to provide:
> > * Corresponding updates to iproute2
> > * Corresponding self tests (which depend on the iproute2 changes)
> 
> I was about to ask :)
> 
> FYI, there is this selftest:
> tools/testing/selftests/net/forwarding/tc_police.sh
> 
> Which can be extended to also test packet rate policing

Thanks Ido,

The approach we have taken is to add tests to
tools/testing/selftests/tc-testing/tc-tests/actions/police.json

Do you think adding a test to tc_police.sh is also worthwhile? Or should be
done instead of updating police.json?

Lastly, my assumption is that the tests should be posted once iproute2
changes they depend on have been accepted. Is this correct in your opinion?

In any case, I'll get moving on posting the iproute2 changes.

> > * Hardware offload support for the NFP driver
> > 
> > Key changes since v2:
> > * Added patches 1 and 2, which makes adding patch 3 safe for existing
> >   hardware offload of the policer action
> > * Re-worked patch 3 so that a TC policer action instance may be configured
> >   for packet-per-second or byte-per-second rate limiting, but not both.
> > * Corrected kdoc usage
> 
> Thanks!

  reply	other threads:[~2021-03-15 14:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 14:08 [PATCH v3 net-next 0/3] net/sched: act_police: add support for packet-per-second policing Simon Horman
2021-03-12 14:08 ` [PATCH v3 net-next 1/3] flow_offload: " Simon Horman
2021-03-12 14:08 ` [PATCH v3 net-next 2/3] flow_offload: reject configuration of packet-per-second policing in offload drivers Simon Horman
2021-03-12 14:08 ` [PATCH v3 net-next 3/3] net/sched: act_police: add support for packet-per-second policing Simon Horman
2021-03-12 14:22 ` [PATCH v3 net-next 0/3] " Simon Horman
2021-03-16 13:53   ` Jamal Hadi Salim
2021-03-16 16:40     ` Simon Horman
2021-03-13 22:40 ` patchwork-bot+netdevbpf
2021-03-14  8:17 ` Ido Schimmel
2021-03-15 14:41   ` Simon Horman [this message]
2021-03-16  8:35     ` Ido Schimmel
2021-03-16 10:42       ` Simon Horman

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=20210315144155.GA2053@netronome.com \
    --to=simon.horman@netronome.com \
    --cc=baowen.zheng@corigine.com \
    --cc=davem@davemloft.net \
    --cc=idosch@idosch.org \
    --cc=kuba@kernel.org \
    --cc=louis.peens@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=xingfeng.hu@corigine.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).