All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trevor Warren <trevorwarren@softhome.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] u32 filter limits?? ....?2000
Date: Mon, 23 Jun 2003 04:14:49 +0000	[thread overview]
Message-ID: <marc-lartc-105638496306541@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105633853301418@msgid-missing>

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/

      parent reply	other threads:[~2003-06-23  4:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-22 15:23 [LARTC] u32 filter limits?? ....?2000 Trevor Warren
2003-06-22 21:32 ` Nickola Kolev
2003-06-23  4:14 ` Trevor Warren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-105638496306541@msgid-missing \
    --to=trevorwarren@softhome.net \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.