[LARTC] prio bands and ignored priomap when any tc filter is present

From: Michal Soltys <nozo@ziu.info>
To: lartc@vger.kernel.org
Subject: [LARTC] prio bands and ignored priomap when any tc filter is present
Date: Tue, 28 Aug 2007 05:02:21 +0000	[thread overview]
Message-ID: <46D3AC5D.3010601@ziu.info> (raw)

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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc