g.
> tc filter add dev tap1 parent : u32 match \
> u32 0 0 police pkts_rate 3000 pkts_burst 1000
>
> [...]
Here is the summary with links:
- [net-next] nfp: flower: add support for packet-per-second policing
https://git.kernel.org/netdev/net-next/c/631a44ed2560
You a
From: Peng Zhang
Allow hardware offload of a policer action attached to a matchall filter
which enforces a packets-per-second rate-limit.
e.g.
tc filter add dev tap1 parent : u32 match \
u32 0 0 police pkts_rate 3000 pkts_burst 1000
Signed-off-by: Peng Zhang
Signed-off-by: Baowen Z
On 3/26/21 6:50 AM, Simon Horman wrote:
> From: Baowen Zheng
>
> Allow a policer action to enforce a rate-limit based on packets-per-second,
> configurable using a packet-per-second rate and burst parameters.
>
> e.g.
> # $TC actions add action police pkts_rate 1000 p
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Fri, 26 Mar 2021 14:09:36 +0100 you wrote:
> Add self tests for the recently added packet per second rate limiting
> feature of the TC policer action[1].
>
> The forwarding selftest (patch 2/2) depends
Add self tests for the recently added packet per second rate limiting
feature of the TC policer action[1].
The forwarding selftest (patch 2/2) depends on iproute2 support
for packet per second rate limiting, which has been posted separately[2]
[1] [PATCH v3 net-next 0/3] net/sched: act_police
From: Baowen Zheng
Allow a policer action to enforce a rate-limit based on packets-per-second,
configurable using a packet-per-second rate and burst parameters.
e.g.
# $TC actions add action police pkts_rate 1000 pkts_burst 200 index 1
# $TC actions ls action police
total acts 1
ction instance to enforce a rate-limit based on
> > > packets-per-second, configurable using a packet-per-second rate and burst
> > > parameters.
> >
> > ...
> >
> > Sorry, I missed CCing a number of interested parties when posting
> > this patch-set
On 2021-03-12 9:22 a.m., Simon Horman 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
Hi Ido,
On Tue, Mar 16, 2021 at 10:35:35AM +0200, Ido Schimmel wrote:
> Sorry for the delay. Was AFK yesterday
No problem at all.
...
> > > > As follow-ups we plan to provide:
> > > > * Corresponding updates to iproute2
> > > > * Corresponding self tests (which depend on the iproute2 changes)
>
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 i
-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
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.
>
e using a packet-per-second rate and burst
> parameters.
>
> In the hope of aiding review this is broken up into three patches.
>
> [...]
Here is the summary with links:
- [v3,net-next,1/3] flow_offload: add support for packet-per-second policing
https://git.kernel.org/netdev
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.
.
From: Baowen Zheng
A follow-up patch will allow users to configures packet-per-second policing
in the software datapath. In preparation for this, teach all drivers that
support offload of the policer action to reject such configuration as
currently none of them support it.
Signed-off-by: Baowen
From: Baowen Zheng
Allow a policer action to enforce a rate-limit based on packets-per-second,
configurable using a packet-per-second rate and burst parameters.
e.g.
tc filter add dev tap1 parent : u32 match \
u32 0 0 police pkts_rate 3000 pkts_burst 1000
Testing was unable to
From: Xingfeng Hu
Allow flow_offload API to configure packet-per-second policing using rate
and burst parameters.
Dummy implementations of tcf_police_rate_pkt_ps() and
tcf_police_burst_pkt() are supplied which return 0, the unconfigured state.
This is to facilitate splitting the offload, driver
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
On 2021-02-01 7:33 a.m., Simon Horman wrote:
On Fri, Jan 29, 2021 at 09:30:00AM -0500, Jamal Hadi Salim wrote:
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
On Mon, Feb 1, 2021 at 5:02 AM Simon Horman wrote:
> Would something like this incremental change your concerns?
Yes of course.
Thanks!
ion 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
On Sat, Jan 30, 2021 at 04:57:38PM +0200, Ido Schimmel wrote:
> On Fri, Jan 29, 2021 at 03:04:51PM -0800, Cong Wang wrote:
> > On Fri, Jan 29, 2021 at 2:29 AM Simon Horman
> > wrote:
>
> I didn't get v2 (didn't made it to the list), but I did leave feedback
> on v1 [1]. Not sure if you got it or
_t(u64, conf->rate, rate64);
r->linklayer = (conf->linklayer & TC_LINKLAYER_MASK);
- psched_ratecfg_precompute__(r->rate_bytes_ps, &r->mult, &r->shift);
+ __psched_ratecfg_precompute(r->rate_bytes_ps, &r->mult, &r->shift);
}
EXPOR
ion 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
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
> >
> > Allow a policer action to enforce a rate-limit based on packets-per-second,
> > configurable using a packet-per-second rate
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
> >
> > Allow a policer action to enforce a rate-limit based on packets-per-second,
> > configurable using a packe
On Fri, Jan 29, 2021 at 03:04:51PM -0800, Cong Wang wrote:
> On Fri, Jan 29, 2021 at 2:29 AM Simon Horman
> wrote:
I didn't get v2 (didn't made it to the list), but I did leave feedback
on v1 [1]. Not sure if you got it or not given the recent issues.
[1] https://lore.kernel.org/netdev/20210128
On Fri, Jan 29, 2021 at 2:29 AM Simon Horman wrote:
> +/**
> + * psched_ratecfg_precompute__() - Pre-compute values for reciprocal division
> + * @rate: Rate to compute reciprocal division values of
> + * @mult: Multiplier for reciprocal division
> + * @shift: Shift for reciprocal division
>
On Mon, Jan 25, 2021 at 04:18:19PM +0100, Simon Horman wrote:
> From: Baowen Zheng
>
> 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
er 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
On Wed, Jan 27, 2021 at 12:59:05PM -0800, Jakub Kicinski wrote:
> On Wed, 27 Jan 2021 12:02:23 +0100 Simon Horman wrote:
> > > > +void psched_ppscfg_precompute(struct psched_pktrate *r,
> > > > + u64 pktrate64)
> > > > +{
> > > > + memset(r, 0, sizeof(*r));
> > > >
On Wed, 27 Jan 2021 12:02:23 +0100 Simon Horman wrote:
> > > +void psched_ppscfg_precompute(struct psched_pktrate *r,
> > > + u64 pktrate64)
> > > +{
> > > + memset(r, 0, sizeof(*r));
> > > + r->rate_pkts_ps = pktrate64;
> > > + r->mult = 1;
> > > + /* The deal here is to repl
Hi Jakub,
On Tue, Jan 26, 2021 at 06:38:12PM -0800, Jakub Kicinski wrote:
> On Mon, 25 Jan 2021 16:18:19 +0100 Simon Horman wrote:
> > From: Baowen Zheng
> >
> > Allow a policer action to enforce a rate-limit based on packets-per-second,
> > configurable using a packe
On Mon, 25 Jan 2021 16:18:19 +0100 Simon Horman wrote:
> From: Baowen Zheng
>
> 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-
From: Baowen Zheng
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
On Thu, 20 Dec 2018 23:06:38 -0800
Saeed Mahameed wrote:
> XDP_TX:
> We see a huge gain on single port ConnectX-5, and reach the 100 Mpps
> milestone.
> * Single-port HCA:
> Before: 70 Mpps
> After: 100 Mpps (+42.8%)
Great, this confirm that we were hitting a PCIe limit in our XD
Hi Dave,
This great series from Tariq is a very big leap and important milestone
for XDP. The XDP TX 100Mpps milestone is reached as Tariq adds the
required hardware support to overcome the pcie and cpu limits with the
ConnectX-5 Multi packet TX WQE feature (MPWQE), it is only a mater of time
to f
[Apologies for off-topic]
On Mon, 2007-12-17 at 11:18 +, Flávio Pires wrote:
> I alread though about something like this. But, isn`t NetFlow just for
> Cisco IOS ?
NetFlow is a trade mark of Cisco Systems Inc (USA).
Packets in the identical format used by NetFlow are produced by
a wide range
On Mon, Dec 17, 2007 at 11:18:57AM +, Flávio Pires wrote:
> In article <[EMAIL PROTECTED]> Glen
> Turner<[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-12-14 at 15:34 +, Flvio Pires wrote:
> >> Well, I work on an ISP and we have a linux box acting as a
> >> bridge+firewall. With this bridge
In article <[EMAIL PROTECTED]> Glen
Turner<[EMAIL PROTECTED]> wrote:
> On Fri, 2007-12-14 at 15:34 +, Flvio Pires wrote:
>> Well, I work on an ISP and we have a linux box acting as a
>> bridge+firewall. With this bridge+firewall we control the packet
>> rate per second from each client and
On Fri, 2007-12-14 at 15:34 +, Flávio Pires wrote:
> Well, I work on an ISP and we have a linux box acting as a
> bridge+firewall. With this bridge+firewall we control the packet rate
> per second from each client and from our repeaters. But I can`t
> measure the packet rate per IP. Is there
In article <[EMAIL PROTECTED]> Stephen
Hemminger<[EMAIL PROTECTED]> wrote:
> On Fri, 14 Dec 2007 15:34:10 + (UTC)
> Flvio Pires <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> It's my first time using usenet...
>>
>> Well, I work on an ISP and we have a linux box acting as a
>> brid
On Fri, 14 Dec 2007 15:34:10 + (UTC)
Flávio Pires <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> It's my first time using usenet...
>
> Well, I work on an ISP and we have a linux box acting as a
> bridge+firewall. With this bridge+firewall we control the packet rate
> per second from each client
Hi all,
It's my first time using usenet...
Well, I work on an ISP and we have a linux box acting as a
bridge+firewall. With this bridge+firewall we control the packet rate
per second from each client and from our repeaters. But I can`t
measure the packet rate per IP. Is there any tool for this?
44 matches
Mail list logo
