Re: Ingress filter is overly aggressive

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Neil Aggarwal wrote:
Hello:

I have these rules set up for an interface:

IP=a.b.c.d
DEV=v1208
/sbin/tc qdisc del dev $DEV root
/sbin/tc qdisc add dev $DEV root handle 1: htb default 30
/sbin/tc class add dev $DEV parent 1: classid 1:1 htb rate 5mbit
/sbin/tc class add dev $DEV parent 1: classid 1:2 htb rate 5mbit
/sbin/tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 match ip dst
$IP flowid 1:1
/sbin/tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 match ip src
$IP flowid 1:2
/sbin/tc qdisc del dev $DEV ingress
/sbin/tc qdisc add dev $DEV ingress handle ffff:
/sbin/tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip
src 0.0.0.0/0 police rate 5mbit burst 500k drop flowid :1

According to these rules, the ingress police rate should be 5 mbit/sec, but
I am barely
getting 50 kbits/sec through the interface.

If I remove the filter, the interface operates at full line rate.

Any ideas why the ingress filter is being so aggressive?

Hmm, I just tested and got the same.

It seems the problem is that you don't specify mtu adding mtu 3100 fixed for me.

I think there is an issue with policer and kernel receive offload - which on my box at least makes it look like double size packets are arriving (you can turn it off with ethtool).

Last time I looked with ifb it seemed that anything on that actually saw the packets as normal size (1514 on eth).

Testing above policer with mtu 1600 doesn't work though (well it works slowly as I guess tcp is eventually beaten into sending one packet at a time), so it seems policer is seeing double size phony packets as mtu 3100 does work.

Policers can be over aggresive even when working eg. though 500k burst seemed to work for one file testing on 100mbit eth I don't know if It would be too big for many connections - but then setting too small is also likely to hurt - needs lots of testing with real workloads I guess.





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


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux