Re: Traffic quota features in IPFW
From: Chris Dionissopoulos (dionch_at_freemail.gr)
Date: 07/16/05
- Previous message: Max Laier: "Re: Traffic quota features in IPFW"
- In reply to: Max Laier: "Re: Traffic quota features in IPFW"
- Next in thread: Luigi Rizzo: "Re: Traffic quota features in IPFW"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: "Max Laier" <max@love2party.net>, <freebsd-ipfw@freebsd.org> Date: Sat, 16 Jul 2005 19:23:27 +0300
>> Hi ppl, ( and sorry for cross posting)
>>
>> I review Andrey's Elsukov patch for adding "bound" support in ipfw, and i
>> decide to push a little forward this feature.
>Sorry to be blunt, but I don't see the point in this feature nor do I think
>it's a good idea. All it does is adding overhead to every packet that is
>processed by IPFW. You might argue that this overhead is fairly little, but
>if you combine the last ten "neat to have though not really necessary"
>features this adds up. Also the code is getting more and more hacked up.
If your rules are not using this option it doesn't adds any overhead.
If your rules using it , it adds as much overhead as any other option you use.
Yes, we see too much patching in ipfw the last 2 months, but I think that
ipfw code still remains plain and clear.
>Your feature might be nicely done, but it adds to the main switch-loops
>making them more and more unreadable until it all falls over and nobody is
>willing to touch the code anymore. I have seen (too) much ipfw code lately
>while tieing together lose ends in the IPv6-import and it's already messy
>enough.
This is the way ipfw is written all these years. I dont know if my codind skills
are not enough, but right now I cannot see any other way to add new features
in ipfw, without using this huge switch checks.
IMHO, ipfw must be hardly rewriten to remove these switch checks.
But again, my opinion is that ipfw's checking is fast enough as is.
Maybe I'm wrong.
>I urge you to reconsider if we really need this. If you think we can't live
>without it, it'd be nice if you could come up with a clean(er) way to extend
>IPFW with additional stuff like this without impact to performance and
>maintainability for the common case (without the magic foobar-option of the
>day). Thanks.
I agree with you, a good reason to drop this patch is if it is useless to
the most of the ipfw users. If I 'm the only one (and Andrey) who need this,
just ignore it. That's why I post it here.
>BTW: This function can be done with a three line awk-skript without any effect
>on performance. Of course you will lose some precision, but I don't see
>applications where you have to be *that* percise.
Hmm, do you have a small example. I 'm really intrested for this, and I can't think
any.
TIA,
Chris.
____________________________________________________________________
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: Max Laier: "Re: Traffic quota features in IPFW"
- In reply to: Max Laier: "Re: Traffic quota features in IPFW"
- Next in thread: Luigi Rizzo: "Re: Traffic quota features in IPFW"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
