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: <4A262BE7.4090807@trash.net>
Date:	Wed, 03 Jun 2009 09:53:11 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	Antonio Almeida <vexwek@...il.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	netdev@...r.kernel.org, davem@...emloft.net, devik@....cz,
	Eric Dumazet <dada1@...mosbay.com>,
	Vladimir Ivashchenko <hazard@...ncoudi.com>
Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed

Jarek Poplawski wrote:
> On Wed, Jun 03, 2009 at 09:06:37AM +0200, Patrick McHardy wrote:
>> Mid-term we really need to move to 64 bit values and ns resolution,
>> otherwise this problem is just going to reappear as soon as someone
>> tries 10gbit. Not sure what the best short term fix is, I feel a bit
>> uneasy about changing the current factors given how close this brings
>> us towards overflowing.
> 
> I completely agree it's on the verge of overflow, and actually would
> overflow for some insanely low (for today's standards) rates. So I
> treat it's as a temporary solution, until people start asking about
> more than 1 or 2Gbit. And of course we will have to move to 64 bit
> anyway. Or we can do it now...

That (now) would certainly be the best solution, but its a non-trivial
task since all the ABIs use 32 bit values.

> Btw., I've some doubts about HFSC; it's really different than others
> wrt. rate tables/time accounting, and these PSCHED_TICKS look only
> like an unnecesary compatibility; it works OK with usecs and doesn't
> need this change now, unless I miss something. So maybe we would
> simply stop using common psched_get_time() for it, and only do a
> conversion for qdisc_watchdog_schedule() etc.?

Yes, it would work perfectly fine with usecs, which is actually (and
unfortunately) the unit it uses in its ABI. But I think its better
to convert the values once during initialization, instead of again
and again when scheduling the watchdog. The necessary changes are
really trivial, all you need to do when changing the scaling factors
is to increase SM_MASK and decrease ISM_MASK accordingly.
--
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