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 17:54:18 +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
Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed

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:

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