prio bands and ignored priomap when any tc filter is present

Linux Advanced Routing and Traffic Control

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

 



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

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