* [LARTC] tc filter scalability
@ 2003-12-17 3:20 John Hanlon - Central Coast Internet
2003-12-17 11:46 ` Ben Efros
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: John Hanlon - Central Coast Internet @ 2003-12-17 3:20 UTC (permalink / raw)
To: lartc
Has anyone tested the scalability of using tc filters? I have a box
which I require to traffic shape each individual client by IP Address using
u32 identifiers. My concern though, is that each client requires 2 filters
(data from and to the box) and there are a few hundred clients minimum.
Which means each packet may have to pass through a few hundred or possibly
thousand filters to determine its path. Is this going to give significant
latency issues? Or excessive server load?
Is there a simpler way to restrict each client to a given rate (there
are three separate rates that different clients are assigned)?
Kind regards,
John Hanlon.
Central Coast Internet.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] tc filter scalability
2003-12-17 3:20 [LARTC] tc filter scalability John Hanlon - Central Coast Internet
@ 2003-12-17 11:46 ` Ben Efros
2003-12-17 14:14 ` Dawid Kuroczko
2003-12-19 1:01 ` John Hanlon - Central Coast Internet
2 siblings, 0 replies; 4+ messages in thread
From: Ben Efros @ 2003-12-17 11:46 UTC (permalink / raw)
To: lartc
I no longer use the filters, instead I use the netfilter module CLASSIFY to
mark packets for certain queues....
----- Original Message -----
From: "John Hanlon - Central Coast Internet" <john@cci.net.au>
To: <lartc@mailman.ds9a.nl>
Sent: Tuesday, December 16, 2003 8:06 PM
Subject: [LARTC] tc filter scalability
> Has anyone tested the scalability of using tc filters? I have a box
> which I require to traffic shape each individual client by IP Address
using
> u32 identifiers. My concern though, is that each client requires 2 filters
> (data from and to the box) and there are a few hundred clients minimum.
> Which means each packet may have to pass through a few hundred or possibly
> thousand filters to determine its path. Is this going to give significant
> latency issues? Or excessive server load?
>
> Is there a simpler way to restrict each client to a given rate (there
> are three separate rates that different clients are assigned)?
>
> Kind regards,
>
> John Hanlon.
> Central Coast Internet.
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] tc filter scalability
2003-12-17 3:20 [LARTC] tc filter scalability John Hanlon - Central Coast Internet
2003-12-17 11:46 ` Ben Efros
@ 2003-12-17 14:14 ` Dawid Kuroczko
2003-12-19 1:01 ` John Hanlon - Central Coast Internet
2 siblings, 0 replies; 4+ messages in thread
From: Dawid Kuroczko @ 2003-12-17 14:14 UTC (permalink / raw)
To: lartc
On Wed, 17 Dec 2003, John Hanlon - Central Coast Internet wrote:
> Has anyone tested the scalability of using tc filters? I have a box
> which I require to traffic shape each individual client by IP Address using
> u32 identifiers. My concern though, is that each client requires 2 filters
> (data from and to the box) and there are a few hundred clients minimum.
> Which means each packet may have to pass through a few hundred or possibly
> thousand filters to determine its path. Is this going to give significant
> latency issues? Or excessive server load?
One thing -- u32 is not a "cascade" (or chain) of filters. If you enter
10000 filter matches for src address, it will _NOT_ mean that to find
10000th host, you would have to "go through" 9999 other. It would be
the case if you used ip tables. u32 is a hash table. A hash key is
calculated from packet entering the kernel, and then this key is
looked up in the table, so there is no difference in speed when
getting first or 10000th target. :-)
Regards,
Dawid
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LARTC] tc filter scalability
2003-12-17 3:20 [LARTC] tc filter scalability John Hanlon - Central Coast Internet
2003-12-17 11:46 ` Ben Efros
2003-12-17 14:14 ` Dawid Kuroczko
@ 2003-12-19 1:01 ` John Hanlon - Central Coast Internet
2 siblings, 0 replies; 4+ messages in thread
From: John Hanlon - Central Coast Internet @ 2003-12-19 1:01 UTC (permalink / raw)
To: lartc
So server load does not change during filtering from the u32 hash into the
relevant class? If there is an individual class for each user however (i.e.
thousands of seperate classes), does that increase load during the CBQ's
polling of each class? Or is the effect negligible?
Kind regards,
John Hanlon.
At 00:14 18/12/03, you wrote:
>On Wed, 17 Dec 2003, John Hanlon - Central Coast Internet wrote:
>
> > Has anyone tested the scalability of using tc filters? I have a box
> > which I require to traffic shape each individual client by IP Address
> using
> > u32 identifiers. My concern though, is that each client requires 2 filters
> > (data from and to the box) and there are a few hundred clients minimum.
> > Which means each packet may have to pass through a few hundred or possibly
> > thousand filters to determine its path. Is this going to give significant
> > latency issues? Or excessive server load?
>
>One thing -- u32 is not a "cascade" (or chain) of filters. If you enter
>10000 filter matches for src address, it will _NOT_ mean that to find
>10000th host, you would have to "go through" 9999 other. It would be
>the case if you used ip tables. u32 is a hash table. A hash key is
>calculated from packet entering the kernel, and then this key is
>looked up in the table, so there is no difference in speed when
>getting first or 10000th target. :-)
>
> Regards,
> Dawid
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-12-19 1:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-17 3:20 [LARTC] tc filter scalability John Hanlon - Central Coast Internet
2003-12-17 11:46 ` Ben Efros
2003-12-17 14:14 ` Dawid Kuroczko
2003-12-19 1:01 ` John Hanlon - Central Coast Internet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.