netdev - Re: [PATCH iproute2] Re: HTB accuracy for high speed

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 May 2009 19:23:14 +0100
From:	Antonio Almeida <vexwek@...il.com>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org,
	kaber@...sh.net, davem@...emloft.net, devik@....cz,
	Eric Dumazet <dada1@...mosbay.com>
Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed

Here's my .config

  Antonio Almeida


On Mon, May 18, 2009 at 6:53 PM, Jarek Poplawski <jarkao2@...il.com> wrote:
> On Mon, May 18, 2009 at 05:54:18PM +0100, Antonio Almeida wrote:
>> I'm not sure if I'm able to test this patch. What do you mean with
>> "smallest sizes"? Are you talking about packet's size? What kind of
>> sizes?
>> When I feed my bridge with 950Mbits/s of packets with 800 bytes that
>> is close to 150.000pps and CPUs start to get busy. For packets 100
>> bytes long, 150.000pps would be close to 125Mbits/s and CPUs start to
>> get busy already, so I'm not able to get close to 500Mbits/s. For
>> rates near 125bits/s the bad accuracy is not so expressive. For
>> packets of 100 bytes increasing analyser sent traffic, at some point
>> is not HTB shaping but the CPU that can't process so many packets. I
>> might misunderstood your point.
>>
>> I applied this tc_core.c patch and for packets of 800 bytes it had no
>> effect in HTB accuracy with rates over 500Mbit.
>> Anyway I also test it with packets of 100 bytes, generating 200Mbits,
>> and the result is the same as without this patch:
>
> You're right: if there were only 800 byte packets this patch shouldn't
> matter. It should matter e.g. if these 800 byte were mixed with 100
> byte packets, rate 550Mbit, and HZ 1000. Btw. if could you send your
> .config (gzipped)? I guess, I've to look for some other reason yet.
>
> Thanks,
> Jarek P.
>
>>
>> With the patch:
>> class htb 1:108 parent 1:10 leaf 108: prio 7 quantum 1514 rate
>> 100000Kbit ceil 100000Kbit burst 14087b/8 mpu 0b overhead 0b cburst
>> 14087b/8 mpu 0b overhead 0b level 0
>>  Sent 2187884640 bytes 22790465 pkt (dropped 8624566, overlimits 0 requeues 0)
>>  rate 124946Kbit 162691pps backlog 0b 0p requeues 0
>>  lended: 22790465 borrowed: 0 giants: 0
>>  tokens: 180 ctokens: 180
>>
>>
>> Without the patch:
>> class htb 1:108 parent 1:10 leaf 108: prio 7 quantum 1514 rate
>> 100000Kbit ceil 100000Kbit burst 14087b/8 mpu 0b overhead 0b cburst
>> 14087b/8 mpu 0b overhead 0b level 0
>>  Sent 1260235680 bytes 13127455 pkt (dropped 4531299, overlimits 0 requeues 0)
>>  rate 124575Kbit 162207pps backlog 0b 0p requeues 0
>>  lended: 13127455 borrowed: 0 giants: 0
>>  tokens: 123 ctokens: 123
>>
>>
>> Thanks
>>   Antonio Almeida
>>
>>
>> On Mon, May 18, 2009 at 7:56 AM, Jarek Poplawski <jarkao2@...il.com> wrote:
>> > Return non-zero tc_calc_xmittime() for rate tables
>> >
>> > While looking at the problem of HTB accuracy for high speed (~500Mbit
>> > rates) I've found that rate tables have cells filled with zeros for
>> > the smallest sizes. It means such packets aren't accounted at all.
>> > Apart from the correctness of such configs, let's make it safe with
>> > rather overaccounting than living it unlimited.
>> >
>> > Reported-by: Antonio Almeida <vexwek@...il.com>
>> > Signed-off-by: Jarek Poplawski <jarkao2@...il.com>
>> > ---
>> >
>> >  tc/tc_core.c |    4 +++-
>> >  1 files changed, 3 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/tc/tc_core.c b/tc/tc_core.c
>> > index 9a0ff39..14f25bc 100644
>> > --- a/tc/tc_core.c
>> > +++ b/tc/tc_core.c
>> > @@ -58,7 +58,9 @@ unsigned tc_core_ktime2time(unsigned ktime)
>> >
>> >  unsigned tc_calc_xmittime(unsigned rate, unsigned size)
>> >  {
>> > -       return tc_core_time2tick(TIME_UNITS_PER_SEC*((double)size/rate));
>> > +       unsigned t;
>> > +       t = tc_core_time2tick(TIME_UNITS_PER_SEC*((double)size/rate));
>> > +       return t ? : 1;
>> >  }
>> >
>> >  unsigned tc_calc_xmitsize(unsigned rate, unsigned ticks)
>> >
>

Download attachment "config.tar" of type "application/x-tar" (15707 bytes)