Yassen Damyanov wrote:
Hi again LARTC list, Andy helped recently to spot a bug in an ematch filter definition that classifies a range of ports (thanks again!) Now I again have a problem with that same classifier, this time on an ifb device which is "connected" to an eth device to allow for richer ingress control: # ip link set dev ifb0 up # tc qdisc add dev eth0 handle ffff: ingress # tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 # tc qdisc add dev ifb0 root handle 1:0 htb # tc class add dev ifb0 parent 1:0 classid 1:1 htb rate 30gbit # tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff flowid 1:1 # tc qdisc add dev ifb0 parent 1:1 handle 2:0 htb # tc class add dev ifb0 parent 2:0 classid 2:1 htb rate 2mbit # tc filter add dev ifb0 parent 2:0 protocol ip prio 1 basic match "cmp(u16 at 2 layer transport gt 8079) and cmp(u16 at 2 layer transport lt 8089)" flowid 2:1 When doing measurements, the speed within the shaped range is way below what would be if no shaping is done, but substantially higher than the htb rate specified (2mbit). It also differs significantly from test to test. If I just put a u32 filter like this: # tc filter add dev ifb0 parent 2:0 protocol ip prio 1 u32 match ip dport 8080 0xffff flowid 2:1 -- this works as expected. I see this in the ematch man page and I guess it might be related, but I am not sure how: """ When using the ipset ematch with the "ifb" device, the outgoing device will be the ifb device itself, e.g. "ifb0". The original interface (i.e. the device the packet arrived on) is treated as the incoming interface. """ Does anyone see what am I missing and how to get that ematch working on the ifb? Thanks!
Seems to work for me with a quick test on lan. Random thoughts - Putting htb qdisc under htb is allowed, but not normal and gets in dmesg "htb: htb qdisc 2: is non-work-conserving?" 30 gig is really high and I see htb sets burst and cburst to 0. Your qlens will be picked up from ifb, default 32 which may be too low for the high bandwidth/htb direct traffic. Nics may be doing hardware/driver software offloads, causing giant packets to hit the qdisc - you can disable with ethtool. -- 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
