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]

Message-ID: <20090518175352.GB2755@ami.dom.local>
Date:	Mon, 18 May 2009 19:53:52 +0200
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Antonio Almeida <vexwek@...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

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