LARTC - Aug 2007 - prio bands and ignored priomap when any tc filter is present

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 ?

Javier Ors wrote:
> I''m not sure but I think that you have to choose either to use the
> priomap, or to use only the filters. I have also notice this problem, if 
> you set a filter for only one kind of traffic the rest of it ends in 
> some random band.
>  
Ok, thanks for confirmation.
> Anyway, the priomap is a mess and for the ip traffic you can do the same 
> that it does (and much more) with just three tc filters.
Well, priomap is just a quick temporary solution here. I''ll be setting
up
hfsc most probably.

 > By the way,
> IMHO all the priomap stuff is not quite clear in the LARTC HOWTO, and 
> have prepared some alternative explanation. Is still the HOWTO accepting 
> aportations? I''ve seen that hasn''t been updated for many
years now.
No idea, I''m not the one to be asked about it :)

Russell Stuart has a bit more complete info about prio here:
http://ace-host.stuart.id.au/russell/files/tc/doc/tc/sch_prio.txt

Really, I only understood what the *priorities* of the priomap were until I
read this other document from him:
http://ace-host.stuart.id.au/russell/files/tc/doc/tc/priority.txt
The document I prepared was just an alternative for the priomap section of
the howto based on this information, the only thing I would add to this
information would be an extra comment at the end:

"- The ToS-to-Linux_Priority mapping is made at the very beggining of the
routing process, even before the packet enters in the iptables chains. This
means that changing the ToS field of the packet with iptable''s "-j
TOS
--set-tos" flags, will not change neither its Linux priority nor the band
it
will be assigned to."

And maybe talk about the fact that the ToS byte has been replaced by the
DiffServ Code Point, but for the moment the priority mapping, and many
common applications are still using the ToS scheme, not other things like
ICMP traffic as far as I''ve seen...
> No idea, I''m not the one to be asked about it :)
Sorry, the question was for the list, I didn''t realized that I was
sending
it only to you, a newbie mistake. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.ds9a.nl/pipermail/lartc/attachments/20070828/e9322c37/attachment.html