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]

Message-ID: <AANLkTikMJ2rtSNsBeaVTsVtw1ZmKpLjjyeYL=c+AgoFZ@mail.gmail.com>
Date:	Wed, 1 Sep 2010 01:00:53 +0400
From:	Dan Kruchinin <dkruchinin@....org>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	netdev@...r.kernel.org, Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	Stephen Hemminger <shemminger@...l.org>
Subject: Re: [RFC][PATCH] QoS TBF and latency configuration misbehavior

On Tue, Aug 31, 2010 at 11:57 PM, Jarek Poplawski <jarkao2@...il.com> wrote:
> Dan Kruchinin wrote, On 08/31/2010 07:01 PM:
>
>> I'm sorry it seems my email client has broken patch formating.
>> Here is properly formated one:
>> diff --git a/tc/q_tbf.c b/tc/q_tbf.c
>> index dc556fe..850e6db 100644
>> --- a/tc/q_tbf.c
>> +++ b/tc/q_tbf.c
>> @@ -178,7 +178,7 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
>>       }
>>
>>       if (opt.limit == 0) {
>> -             double lim = opt.rate.rate*(double)latency/TIME_UNITS_PER_SEC + buffer;
>> +             double lim = opt.rate.rate*(double)latency/TIME_UNITS_PER_SEC;
>
> The way limit is calculated here from latency suggests some safety defaults
> are taken wrt. the implementation, which could be omitted while setting the
> limit directly. You try to change/fix this to adhere to the documentation,
> but such a change would definitely break many user configs, so I doubt it's
> the right solution here. Probably you should rather think about fixing the
> manual.

Thank you for comments.
The only thing that embarrasses me abut documentation fixing is that
the latency loses all its sense.
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.
Moreover, user can pass "limit" value to tc directly and if this limit
value is less than burst size then latency will be improperly
calculated(it'll have a negative value) which is not good as well.
By the way, the following descriptions of TBF algorithm are proposed
the same the manual says:
http://www.opalsoft.net/qos/DS-24.htm
ww.docum.org/docum.org/docs/other/tbf02_kw.ps

If the documentation should be fixed I'm not sure that latency can be
somehow logically described to have any sense at all.

>
> Thanks,
> Jarek P.
>
> --
> 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
>

-- 
W.B.R.
Dan Kruchinin
--
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