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

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxx) 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@xxxxxxxxxxxxxxxxxxxxxx  __   /~\
|  \) /  Pre Sales Consultant - Red Hat     \ (/ |
|_|_  \    9820349221(M) | 22881326(O)      / _|_|
       \___________________________________/



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux