From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Thu, 09 May 2013 10:21:57 +0000 Subject: Re: Can't get the ingress policer to work Message-Id: <518B78C5.2030204@gmail.com> List-Id: References: <518B64EE.8060503@open-t.co.uk> In-Reply-To: <518B64EE.8060503@open-t.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Sebastian Arcus wrote: > I'm trying to limit the bandwidth on the ingress leg of my Internet > connection. I'm using the code from lartc.org: > > > tc qdisc add dev eth0 handle ffff: ingress > > tc filter add dev eth0 parent ffff: protocol ip prio 50 \ > u32 match ip src 0.0.0.0/0 police rate 500kbit \ > burst 10k drop flowid :1 > > > I've tried rates of 1Mbit, 10Mbit, 100Mbit. I've tried bursts of 1k, > 10k, 100k, 1000k. Nothing seems to make any difference. The test > download starts at about 20Mbytes/second - then keeps on slowing down > and stalling intermittently all the way down to 6kbytes/second. Then it > bobs up and down, stalling all the time, between 5kbytes/second and > 17kbytes/second. There seems to be absolutely no relation between the > rate I set and the resulting download rate. > > I'm testing on two VM's. With no traffic shaping on, I get about 36 > megabytes/second clean speed between the two vms. Kernel on both sides > is 3.8.4. I'm only applying traffic shaping on one of the vm's. > > Any suggestions would be much appreciated. I ran out of ideas so far. > I've reread the tc-htb man page, searched google on the ingress queue - > but can't see what am I missing. I've never tested with a virtual machine so don't know exactly what to do. The issue is that by default the kernel/driver will aggregate inbound packets into larger ones and this doesn't work well with policers default mtu setting as it drops them. I have suggested mtu 3100 in the past as an extra parameter as it happened to work on a quick test on a real 100m nic - maybe for vm you need to go higher, or just turn off any sort of offload for the virtual device with ethtool and see if that helps. ethtool -k to see what the settings are (generic-receive-offload is likely the culprit) and eg. ethtool -K gro off