Date: Thu, 23 Apr 1998 22:05:28 -0700 From: Julian Elischer <julian@whistle.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: kjc@csl.sony.co.jp, current@FreeBSD.ORG Subject: Re: Bandwidth throttling etc. Message-ID: <35401D98.6201DD56@whistle.com> References: <199804240305.FAA20329@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: [...] > On this issue: i am looking at the integration of my dummynet stuff > within the ipfw code (mainly to use the classifier and ipfw control > routines already there). > > looking at the ip_fw_chk routine, it returns a 32-bit identifier which > is currently 0, -1, or the port number (extended to 32-bit) for divert. > This value is used in case of divert also to avoid that the same rule > is applied twice. yep, I've just been looking at that.. > > I was thinking to change the return value from the divert port number > to the pointer (index ?) to the matching rule in the firewall check > (and since this is a 16-bit number, the remaining bits can be used > as flags for keep, discard, ...). I think I would rather make it a pointer to the rule.. Index is somehow depending on the storage form of the rules.. I was thinking at one stage of making it the rule number of where to restart processing :-) > > This would have a number of advantages in my opinion, including > the ability to do more complex processing since the rule can contain > specific info on what to do on the packet, and maybe even faster/better > processing when a packet has to do multiple pass through the classifier > (as in the case of the divert, but also dummynet, or bandwith limiters). I've been looking at making the stored line-number in the SKIPTO rules be actual pointers to the rule to skip to. this would require reference counting rules, but it would make it much more efficient to break the rulesets into smaller subgroups, as you wouldn't have to step through every rule. > > > What I wnat to do is to add a field to the mbuf pkhdr field that > > can hold a reference to a flow label or a CBQ class (as a > > specific example) so that the classification of a packet is > > available at any time once made. I then want to add code to > > the IPFW classifier to allow it to make that classification. > > could you use the pointer to the rule as flow label ? of course, then the rule could hold a pointer to whatever you had assigned to it.. :-) > > And how hard (i.e. impact to the rest of the code) would it be to > put the flow label in the mbuf header ? > no real impact.. M_FREE would need to be tought how to free it if it were present.. that's about all. > > Incoming flow control will only really work for TCP, but that is enough > > should you rather say "will only really work for responsive flows" ? yeah I'm presently doing it slightly differently, with a natd-like daemon. I just read your paper/code on the round-robin queueing.. I guess you and kenjiro chen have been working on similar things.. :-) Even thugh I'm not doing input bandwidth control with embedded flows I still thing that a flow capabilty in freeBSD, associated with the packet filter(s) is something that should be investigated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35401D98.6201DD56>