Today I've noticed a bit strange (?) behaviour when prio qdisc is used. Example (having no filters/qdisc/etc. at the start) : Add simple 9 bands qdisc, set each mapping to lowest priority band: tc qdisc add dev $eth root handle 1: prio bands 9 priomap 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 If I do just that, all is fine - whole traffic ends in 9th band, what can easily be verified by tc -s class show dev $eth But, if I added following filter: tc filter add dev $eth parent 1:0 protocol arp prio 1 u32 classid 1:1 match u32 0 0 I can immediately see traffic landing in extra bands (arp excluding, which keeps going to the 1st band). In my case, small example: class prio 1:1 parent 1: Sent 35723 bytes 841 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:2 parent 1: Sent 3681 bytes 46 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:3 parent 1: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:4 parent 1: Sent 25814 bytes 431 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:5 parent 1: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:6 parent 1: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:7 parent 1: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:8 parent 1: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class prio 1:9 parent 1: Sent 75039 bytes 887 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Majority of the traffic still goes to 1:9, as it should for packets unclassified by the filter, but why are there packets in 1:2 and 1:4 ? Simple workaround is just to add catch-all u32 filter with the lowest priority at the end, still - is this intended behaviour ? _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
