The "tc filter .. police" command does not have parameter "limit"

The "tc filter .. police" command does not have parameter "limit"

[Fengyu Gao]

Hi,

I have a question about the "tc filter ... police" command. This
command is similar to the token bucket filter. Under Linux, ingress
traffic can be redirected to an imq or ifb, then you can apply a tbf
there.

However, tbf has an important parameter "limit", which is the size of
the buffer for waiting packets, and it is different from the "burst"
parameter. In the "tc filter ... police" command, there does not seem
to be a "limit" parameter, and there seems to be no document or
discussions about it. Digging into the Linux kernel might be a bit
difficult for me. So my question is what is the buffer size in this
case?

Thanks

Re: The "tc filter .. police" command does not have parameter "limit"

[Andy Furniss]

Fengyu Gao wrote:
> Hi,
>
> I have a question about the "tc filter ... police" command. This
> command is similar to the token bucket filter. Under Linux, ingress
> traffic can be redirected to an imq or ifb, then you can apply a tbf
> there.
>
> However, tbf has an important parameter "limit", which is the size
> of the buffer for waiting packets, and it is different from the
> "burst" parameter. In the "tc filter ... police" command, there does
> not seem to be a "limit" parameter, and there seems to be no document
> or discussions about it. Digging into the Linux kernel might be a
> bit difficult for me. So my question is what is the buffer size in
> this case?

Policers do not buffer and as a result can be a bit aggressive.

IIRC the burst parameter is like a virtual buffer but policers
never hold the packets  - just pass or drop.

Personally I would rather shape but then you have to consider latency
added by buffering. To avoid this you may need to classify traffic to
give latency sensitive priority.

fq_codel could be worth investigating as a single qdisc alternative to a
policer.

Re: The "tc filter .. police" command does not have parameter "limit"

[Dave Taht]

On Sun, Aug 3, 2014 at 6:06 PM, Andy Furniss <adf.lists@gmail.com> wrote:
> Fengyu Gao wrote:
>>
>> Hi,
>>
>> I have a question about the "tc filter ... police" command. This
>> command is similar to the token bucket filter. Under Linux, ingress
>> traffic can be redirected to an imq or ifb, then you can apply a tbf
>> there.
>>
>> However, tbf has an important parameter "limit", which is the size
>> of the buffer for waiting packets, and it is different from the
>> "burst" parameter. In the "tc filter ... police" command, there does
>> not seem to be a "limit" parameter, and there seems to be no document
>> or discussions about it. Digging into the Linux kernel might be a
>> bit difficult for me. So my question is what is the buffer size in
>> this case?
>
>
> Policers do not buffer and as a result can be a bit aggressive.

+1

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

>
> IIRC the burst parameter is like a virtual buffer but policers
> never hold the packets  - just pass or drop.
>
> Personally I would rather shape but then you have to consider latency
> added by buffering. To avoid this you may need to classify traffic to
> give latency sensitive priority.
>
> fq_codel could be worth investigating as a single qdisc alternative to a
> policer.

What I am doing with reasonable success is using act_mirred, with an
inbound ifb device, + htb + fq_codel

A simple example here: http://wiki.gentoo.org/wiki/Traffic_shaping

(note that the fq_codel target and interval should be increased to account for
 an MTU's worth of packets at below 3mbit)

A more complex example can be had in various qos scripts, the sqm
scripts in cerowrt also do inbound diffserv squashing and a few other
tricks.

https://github.com/dtaht/ceropackages-3.10/tree/master/net/sqm-scripts/files/usr/lib/sqm

While somewhat openwrt specific by default they can be easily used with any
modern linux kernel.

>
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article