netdev - Re: [RFC][PATCH] QoS TBF and latency configuration misbehavior

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:	Wed, 1 Sep 2010 01:48:08 +0400
From:	Alexey Kuznetsov <kuznet@....inr.ac.ru>
To:	Dan Kruchinin <dkruchinin@....org>
Cc:	Jarek Poplawski <jarkao2@...il.com>, netdev@...r.kernel.org,
	Stephen Hemminger <shemminger@...l.org>
Subject: Re: [RFC][PATCH] QoS TBF and latency configuration misbehavior

Hello!

> Documentation describes latency as something intuitively clear: "the
> maximum amount of time a packet can sit in the TBF"
> but tc implementation handles it something like: "an additional time
> packet can sit int the TBF after main waiting queue which size is
> equal to the burst size is completely full.". It doesn't seem to have
> any sense.

Seems, I still can tell what I really meant there:
burst is supposed to be handled instantly (unless peak rate is not infinite).
So that, latency is really (limit - burst)/rate.
Indeed, the case when limit < burst was missed in tc,
latency should be 0 in this case.

So, think: formula latency = limit/rate, which you suggest, is obviously
wrong (correct me): everything which is out of bucket is drained with rate of tbf,
but everyhing inside the burst is drained with rate of the device, which
cannot even be estimated on base of tbf parameters. (Again, here I ignore
the case when peak rate is set)

So, it looks like tc is almost correct, only it should print 0 instead
of negative value. And the phrase in documentation should sound like:
"maximal queuing delay introduced by TBF".

Alexey

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