netdev - Re: Does tc-prio really work as advertised?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 27 Nov 2007 13:29:25 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Jarek Poplawski <jarkao2@...pl>
CC:	Joerg Pommnitz <pommnitz@...oo.com>, netdev@...r.kernel.org
Subject: Re: Does tc-prio really work as advertised?

Jarek Poplawski wrote:
> On Tue, Nov 27, 2007 at 02:54:10AM -0800, Joerg Pommnitz wrote:
>> Jarek,
>> this is all about outgoing packets, e.g. egress to use your word.
>> It doesn't matter whether the packets are originated locally or
>> whether the packets are forwarded from another host (I tried
>> both).
>>
>> To restate the problem: according to my observations the prio qdisc
>> (and probably pfifo_fast, but I couldn't observe this) does not prioritize
>> at all and always uses the band indicated by the first entry in the
>> priomap.
>>
>> By default the priomap looks like this:
>> qdisc prio 1: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
>>
>> there are 3 bands (1:1, 1:2 and 1:3). In theory the traffic should go through
>> the different bands according to the TOS value of the packets. My observation
>> is, that the traffic always uses the band pointed to by the first entry in the
>> priomap. This value is 1 by default, so all traffic goes through band 1:2.
>>
>> Now it's entirely possible that I did something stupid, but nobody came forward
>> to show me the error of my ways (neither here nor on the lartc list).
>>
> 
> I don't think there could be anything stupid if something is maybe not
> enough documented. But, this really should work - just like you've
> found: TOS should be recalculated to skb->priority, and this should
> affect prio. You should only consider that this recalculation isn't
> done for all packets, but only forwarded ones (if I can remember, didn't
> miss something, and nothing changed later...). So, are you still sure
> you've tested such a case? (Btw., there are some other tools which can
> change this priority field, so I hope you don't use them too.)


It works fine here, I'm guessing that Jörg is using an old kernel
version that had a bug in prio classification without filters.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html