netdev - RE: [PATCH] net: sched: tbf: fix calculation of max

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, 25 Nov 2013 12:22:30 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Yang Yingliang" <yangyingliang@...wei.com>,
	"Eric Dumazet" <eric.dumazet@...il.com>
Cc:	"netdev" <netdev@...r.kernel.org>, <davem@...emloft.net>,
	<brouer@...hat.com>, <jpirko@...hat.com>, <jbrouer@...hat.com>
Subject: RE: [PATCH] net: sched: tbf: fix calculation of max_size

> From: Yang Yingliang <yangyingliang@...wei.com>
> 
> Current max_size is caluated from rate table. Now, the rate table
> has been replaced and it's wrong to caculate max_size based on this
> rate table. It can lead wrong calculation of max_size.
> 
> The burst in kernel may be lower than user asked, because burst may gets
> some loss when transform it to buffer(E.g. "burst 40kb rate 30mbit/s")
> and it seems we cannot avoid this loss. And burst's value(max_size) based
> on rate table may be equal user asked. If a packet's length is max_size,
> this packet will be stalled in tbf_dequeue() because its length is above
> the burst in kernel so that it cannot get enough tokens. The max_size guards
> against enqueuing packet sizes above q->buffer "time" in tbf_enqueue().

Why not adjust the calculations so that the number of allocated tokens
can go negative?

So allow the transfer if the number of tokens is +ve and then subtract
the number needed for the message itself.

I think this would change the semantics of the configured 'burst' value
very slightly (to 'at least' from 'at most') but the average would still
be correct.

FWIW I've done similar rate limiters that run directly in units of 'time'.
The fact that system time advances automatically generates credit.

	David