Trevor Warren
2003-Jul-02 22:01 UTC
Re: some can help out with u32 & TBF limitation < 2048 only
Thanks for the same martin. Am working on the same and will send the results of the script back to the list. Trevor On Thu, 2003-07-03 at 13:42, devik wrote:> 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@redhat.com __ /~\ > > | \) / Pre Sales Consultant - Red Hat \ (/ | > > |_|_ \ 9820349221(M) | 22881326(O) / _|_| > > \___________________________________/ > >-- ( >- LINUX, It''s all about CHOICE -< ) /~\ __ twarren@redhat.com __ /~\ | \) / Pre Sales Consultant - Red Hat \ (/ | |_|_ \ 9820349221(M) | 22881326(O) / _|_| \___________________________________/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
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@redhat.com __ /~\
> | \) / Pre Sales Consultant - Red Hat \ (/ |
> |_|_ \ 9820349221(M) | 22881326(O) / _|_|
> \___________________________________/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/