Re: [LARTC] u32 filter limits?? ....?2000

Re: [LARTC] u32 filter limits?? ....?2000

[Trevor Warren]

Hey Nickola,

 Yep, this surely is a feature/bug of tc which deems clarification. Hope
someone can come around with a fix for the same.

 As for your setup, can i humbly request you to send across the script
such that i can test the same on my setup.....that is if you don't mind.
Also, i was under the presumtion that flowid was used only when iptables
is used to mark these outgoing packets. 

 Since i don't use iptables i have stuck to plain u32 filters. Lemme
know Nickola and i will try changing the classid to flowid and give this
one a shot.

 Any points at optimising the same folks???.

Trevor


On Mon, 2003-06-23 at 02:47, Nickola Kolev wrote:
> Hey again, Trevor,
> 
> [ cut ]
>  :  Thanks for the prompt reply. Am indeed glad that htb scales to my
>  : enterprise requirements. I have performed tests on my Athlon 1.7Ghz but
>  : still use my dell latitude for r and d.
> 
> I also changed a bit my testbed, just to overclock the CPU to 863MHz (though
> it is the same Duron@750) and to add some 256MB of RAM, which totals 512.
> 
> [ cut ]
>  :  I have tested the same time and again and am convinced this issue needs
>  : to be clarified on.
> 
> Obviously, and you'll see I'm backing you later on.
> 
>  : * Uptill 2000 U32 Filters and htb classes everything is fine
>  : * Above 2000....i am very clear that probably htb classes formation
>  : happens seamlessly but U32 filters stat throwing some stupid errors.
> 
> In my test, tc started throwing errors at u32 filter, attached to classid 2048
> 
> tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst \
> 192.168.20.48/32 classid 1:2048
> RTNETLINK answers: File exists
> 
> I'm not sure if htb classids (or better u32 classids) are limited to 2048 (dec),
> which equals 800(hex). I'm sorry, but I can't read sources, otherwise I could
> peek into Martin Devera's work to search for an answer.
> 
>  : * "RTNETLINK answers: No such file or directory"  thrown up for filters
>  : greater than 2000. Not exactly sure on which number...but very surely
>  : above 2000.
> 
> In my case, tc answered "RTNETLINK answers: File exists" after adding u32
> classifier to classid 2048. This is probably not the case, because in
> my production setup, I have classids much higher than 2048, e.g.:
> 
> tc class add dev eth0 parent $HOME64_CLASS classid 1:14116 htb \
> rate $HOME64_CHILD ceil $HOME64_SPEED burst 12k quantum 1514
> tc filter add dev eth0 protocol ip parent 1:0 prio $HOME64_PRIO u32 \
> match ip dst 10.10.8.79 flowid 1:14116
> tc qdisc add dev eth0 parent 1:14116 handle 14116: sfq quantum 1514b perturb 10
> 
> here HOME64_CHILD, HOME64_SPEED and HOME64_PRIO are variables, taking
> part in the script.
> 
>  :  Any idea on whats wrong with my setup. Does this necessitate change in
>  : use of U32 filters. Can this be avoided???. Or am i on the wrong
>  : track???.
> 
> Keeping in mind I wrote the above, I notice that I'm using a bit
> different sintax, i.e. attaching u32 classifiers to "flowid", not to
> "classid", as in your setup. But nevertheless, the resulst is a 
> 
> RTNETLINK answers: File exists
> 
>  :  Any pointers towards resolving the same will be appreciated. Am
>  : attaching the 4000  approx user script along.
> 
> Personally I can't help, obviously. Am I missing something? I tend to
> be erroneous, but this is beyound the scope of my knowledge. ;)
> 
> Martin Devera? Stef Coene? Martin Brown? Leonardo Baliache?
> 
> Well, If I missed someone more deep-in-this-stuff, please, excuse me,
> but I would also be very interested in clarifying this.
-- 
( >-    GNU/LINUX, It's all about CHOICE      -< )
/~\    __  trevor@clovertechnologies.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/

Re: [LARTC] u32 filter limits?? ....?2000

[Nickola Kolev]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

Hey again, Trevor,

[ cut ]
 :  Thanks for the prompt reply. Am indeed glad that htb scales to my
 : enterprise requirements. I have performed tests on my Athlon 1.7Ghz but
 : still use my dell latitude for r and d.

I also changed a bit my testbed, just to overclock the CPU to 863MHz (though
it is the same Duron@750) and to add some 256MB of RAM, which totals 512.

[ cut ]
 :  I have tested the same time and again and am convinced this issue needs
 : to be clarified on.

Obviously, and you'll see I'm backing you later on.

 : * Uptill 2000 U32 Filters and htb classes everything is fine
 : * Above 2000....i am very clear that probably htb classes formation
 : happens seamlessly but U32 filters stat throwing some stupid errors.

In my test, tc started throwing errors at u32 filter, attached to classid 2048

tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst \
192.168.20.48/32 classid 1:2048
RTNETLINK answers: File exists

I'm not sure if htb classids (or better u32 classids) are limited to 2048 (dec),
which equals 800(hex). I'm sorry, but I can't read sources, otherwise I could
peek into Martin Devera's work to search for an answer.

 : * "RTNETLINK answers: No such file or directory"  thrown up for filters
 : greater than 2000. Not exactly sure on which number...but very surely
 : above 2000.

In my case, tc answered "RTNETLINK answers: File exists" after adding u32
classifier to classid 2048. This is probably not the case, because in
my production setup, I have classids much higher than 2048, e.g.:

tc class add dev eth0 parent $HOME64_CLASS classid 1:14116 htb \
rate $HOME64_CHILD ceil $HOME64_SPEED burst 12k quantum 1514
tc filter add dev eth0 protocol ip parent 1:0 prio $HOME64_PRIO u32 \
match ip dst 10.10.8.79 flowid 1:14116
tc qdisc add dev eth0 parent 1:14116 handle 14116: sfq quantum 1514b perturb 10

here HOME64_CHILD, HOME64_SPEED and HOME64_PRIO are variables, taking
part in the script.

 :  Any idea on whats wrong with my setup. Does this necessitate change in
 : use of U32 filters. Can this be avoided???. Or am i on the wrong
 : track???.

Keeping in mind I wrote the above, I notice that I'm using a bit
different sintax, i.e. attaching u32 classifiers to "flowid", not to
"classid", as in your setup. But nevertheless, the resulst is a 

RTNETLINK answers: File exists

 :  Any pointers towards resolving the same will be appreciated. Am
 : attaching the 4000  approx user script along.

Personally I can't help, obviously. Am I missing something? I tend to
be erroneous, but this is beyound the scope of my knowledge. ;)

Martin Devera? Stef Coene? Martin Brown? Leonardo Baliache?

Well, If I missed someone more deep-in-this-stuff, please, excuse me,
but I would also be very interested in clarifying this.

-- 
_____________________________________________________________

So long, and thanks for all the fish.

Nickola

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] u32 filter limits?? ....?2000

[Trevor Warren]

On Sun, 2003-06-22 at 20:41, Trevor Warren wrote:
> Hey Nickola,
> 
>  Yep, this surely is a feature/bug of tc which deems clarification. Hope
> someone can come around with a fix for the same.
> 
>  As for your setup, can i humbly request you to send across the script
> such that i can test the same on my setup.....that is if you don't mind.
> Also, i was under the presumtion that flowid was used only when iptables
> is used to mark these outgoing packets. 
> 
>  Since i don't use iptables i have stuck to plain u32 filters. Lemme
> know Nickola and i will try changing the classid to flowid and give this
> one a shot.
> 
>  Any points at optimising the same folks???.
> 
> Trevor
> 
> 
> On Mon, 2003-06-23 at 02:47, Nickola Kolev wrote:
> > Hey again, Trevor,
> > 
> > [ cut ]
> >  :  Thanks for the prompt reply. Am indeed glad that htb scales to my
> >  : enterprise requirements. I have performed tests on my Athlon 1.7Ghz but
> >  : still use my dell latitude for r and d.
> > 
> > I also changed a bit my testbed, just to overclock the CPU to 863MHz (though
> > it is the same Duron@750) and to add some 256MB of RAM, which totals 512.
> > 
> > [ cut ]
> >  :  I have tested the same time and again and am convinced this issue needs
> >  : to be clarified on.
> > 
> > Obviously, and you'll see I'm backing you later on.
> > 
> >  : * Uptill 2000 U32 Filters and htb classes everything is fine
> >  : * Above 2000....i am very clear that probably htb classes formation
> >  : happens seamlessly but U32 filters stat throwing some stupid errors.
> > 
> > In my test, tc started throwing errors at u32 filter, attached to classid 2048
> > 
> > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst \
> > 192.168.20.48/32 classid 1:2048
> > RTNETLINK answers: File exists
> > 
> > I'm not sure if htb classids (or better u32 classids) are limited to 2048 (dec),
> > which equals 800(hex). I'm sorry, but I can't read sources, otherwise I could
> > peek into Martin Devera's work to search for an answer.
> > 
> >  : * "RTNETLINK answers: No such file or directory"  thrown up for filters
> >  : greater than 2000. Not exactly sure on which number...but very surely
> >  : above 2000.
> > 
> > In my case, tc answered "RTNETLINK answers: File exists" after adding u32
> > classifier to classid 2048. This is probably not the case, because in
> > my production setup, I have classids much higher than 2048, e.g.:
> > 
> > tc class add dev eth0 parent $HOME64_CLASS classid 1:14116 htb \
> > rate $HOME64_CHILD ceil $HOME64_SPEED burst 12k quantum 1514
> > tc filter add dev eth0 protocol ip parent 1:0 prio $HOME64_PRIO u32 \
> > match ip dst 10.10.8.79 flowid 1:14116
> > tc qdisc add dev eth0 parent 1:14116 handle 14116: sfq quantum 1514b perturb 10
> > 
> > here HOME64_CHILD, HOME64_SPEED and HOME64_PRIO are variables, taking
> > part in the script.
> > 
> >  :  Any idea on whats wrong with my setup. Does this necessitate change in
> >  : use of U32 filters. Can this be avoided???. Or am i on the wrong
> >  : track???.
> > 
> > Keeping in mind I wrote the above, I notice that I'm using a bit
> > different sintax, i.e. attaching u32 classifiers to "flowid", not to
> > "classid", as in your setup. But nevertheless, the resulst is a 
> > 
> > RTNETLINK answers: File exists
> > 
> >  :  Any pointers towards resolving the same will be appreciated. Am
> >  : attaching the 4000  approx user script along.
> > 
> > Personally I can't help, obviously. Am I missing something? I tend to
> > be erroneous, but this is beyound the scope of my knowledge. ;)
> > 
> > Martin Devera? Stef Coene? Martin Brown? Leonardo Baliache?
> > 
> > Well, If I missed someone more deep-in-this-stuff, please, excuse me,
> > but I would also be very interested in clarifying this.
-- 
( >-    GNU/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/