I just looked into u32 source and sent
mail to Alexey regarding some internals.
But at this time I can observe some things:
1) if you don't specify handle for u32 filter, new one will
be assigned from NODE range (0-0x7ff)|0x800. Here you
have 2048 limit probably.
2) even with 2000 classes it will be slow as for each packet
all 2000 filers are looked-up linearly.
To speed it up and make the range greater you need to use
hashing ability of u32 (see divisor parameter). Then you
can use last byte in IP as hash value and use up to 2048
sub-filters per such byte.
Thus you can simply extend range to 500.000 filters. If
you assign some node ids manually then to 1.000.000.
I'd suggest you to use 2 level hash table instead. It will
allow you to hash on 16bits of IP address (65.000 classes)
and it will be 2000times faster than your current approach.
See u32 manual (maybe on lartc?) on how to setup hash
tables ...
I hope I didn't make mistake in my ideas - maybe Alexey
will correct it.
-------------------------------
Martin Devera aka devik
Linux kernel QoS/HTB maintainer
http://luxik.cdi.cz/~devik/
On 2 Jul 2003, Trevor Warren wrote:
>
> Hello Folks,
>
> Some time ago i posted a mail on this list regarding the traffic
> shaping script i devised based on htb and u32. The limitations of which
> are 2048 filters + htb classes.
>
> I am in a deep fix without a resolution for the same. HTB is really
> cewl as it delivers on its functionality, but this lack of scalability
> issue is a pain in me **** cause of which some server deployments are on
> hold.
>
> Thanks in advance and would be glad to hear from anyone. The resolution
> for the same when i find out i will post it on the mailing list.
>
> Trevor
>
>
> --
> ( >- LINUX, It's all about CHOICE -< )
> /~\ __ twarren@xxxxxxxxxx __ /~\
> | \) / Pre Sales Consultant - Red Hat \ (/ |
> |_|_ \ 9820349221(M) | 22881326(O) / _|_|
> \___________________________________/
>
