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:	Sat, 14 Aug 2010 20:27:17 +0300
From:	Jussi Kivilinna <jukivili@...il.com>
To:	"Andrew Beverley" <andy@...ybev.com>
Cc:	"Jesper Dangaard Brouer" <hawk@...u.dk>,
	"Julien Vehent" <julien@...uxwall.info>,
	"Philip A. Prindeville" <philipp_subx@...fish-solutions.com>,
	Netdev <netdev@...r.kernel.org>,
	netfilter <netfilter@...r.kernel.org>, hawk@...x.dk
Subject: Re: QoS weirdness : HTB accuracy

Quoting "Andrew Beverley" <andy@...ybev.com>:

> On Wed, 2010-07-07 at 18:07 +0300, Jussi Kivilinna wrote:
>> >>>> I was, in fact, an error in my ruleset. I had put the  
>> 'linklayer atm' at
>> >>>> both the branch and leaf levels, so the overhead was computed twice,
>> >>>> creating those holes in the bandwidth.
>> >>>
>> >>> I am seeing similar behaviour with my setup. Am I making the same
>> >>> mistake? A subset of my rules is as follows:
>> >>>
>> >>> tc qdisc add dev ppp0 root handle 1: htb r2q 1
>> >>>
>> >>> tc class add dev ppp0 parent 1: classid 1:1 htb \
>> >>>    rate ${DOWNLINK}kbit ceil ${DOWNLINK}kbit \
>> >>>    overhead $overhead linklayer atm                   <------- Here
>> >>>
>> >>> tc class add dev ppp0 parent 1:1 classid 1:10 htb \
>> >>>    rate 612kbit ceil 612kbit prio 0 \
>> >>>    overhead $overhead linklayer atm                   <------- And here
>> >>>
>> >>> tc qdisc add dev ppp0 parent 1:10 handle 4210: \
>> >>>    sfq perturb 10 limit 50
>> >>>
>> >>> tc filter add dev ppp0 parent 1:0 protocol ip \
>> >>>    prio 10 handle 10 fw flowid 1:10
>> >>
>> >> I removed the overhead option on the first leaf, and the speeds change
>> >> to what I expect. However, the rules above are taken straight from the
>> >> ADSL Optimizer project, which was the source of the original overhead
>> >> patch for tc. So is the ADSL Optimizer project wrong?
>> >
>> > After looking at the HTB kernel code I believe that the ADSL
>> > Optimizer project is NOT wrong.  You should/must set the linklayer
>> > option on both the root class and leaf (else you would be charging
>> > the root/parent node too little).
>> >
>>
>> It's been while I looked at the linklayer/size-table code, but if I
>> remember right overhead is calculated with first linklayer packet sees
>> in qdisc. So when packet goes to leaf with 'linklayer atm', packet get
>> packet size with overhead for ATM and root linklayer is not used for
>> that packet. Because of this you can have leafs with different
>> overheads (pppoe, ipv6-tunnel, etc, with ) and all get right
>> overhead... ..
>>
>> ..
>>
>> ...Uh oh...
>>
>> HTB still has linklayer/overhead of its own, I was talking about the
>> generic linklayer code that can be used with all qdiscs. Never mind,
>> sorry.
>
> Ah, I hadn't come across the tc-stab functionality until now. So that
> does exactly the same for all qdiscs as the original ATM patch does for
> HTB? But they work slightly differently as you have alluded to above?
>

Yes, tc-stab works with all qdiscs. Packet size is calculated  
everytime when qdisc_enqueue() is called and qdisc has size-table set.  
When none of qdiscs has size-table, packet size ends up being same as  
skb->len. So if leaf has size-table, that takes preference over  
earlier parent size-tables.

-Jussi

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ