Date: Fri, 24 Apr 1998 07:48:54 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: julian@whistle.com (Julian Elischer) Cc: kjc@csl.sony.co.jp, current@FreeBSD.ORG Subject: Re: Bandwidth throttling etc. Message-ID: <199804240548.HAA20491@labinfo.iet.unipi.it> In-Reply-To: <35401D98.6201DD56@whistle.com> from "Julian Elischer" at Apr 23, 98 10:05:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. right. as a matter of fact, the ipfw "rules" are really a program so i wonder if it wouldn't be better to define a simple language (bytecode ?) such that /sbin/ipfw compiles a "program" into bytecode that is passed to the kernel ... the flow id is really used as the 'program counter' from where to restart processing when you enter the filter... > > 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. Just looking at TCP/IP Ill. vol.2 -- sec.2 where mbufs are defined. It appears that the pointer could go into the struct pkthdr (Figure 2.8) since it is only meaningful there. MHLEN should be reduced accordingly (comes for free in our code since this is computed by difference between MSIZE and sizeof(struct pkthdr) ). Other than that, are you aware of any userland code that could be affected by the change ? Otherwise i am going to do the change (in my sources) next week if you don't do it before... > I just read your paper/code on the round-robin queueing.. > I guess you and kenjiro chen have been working on similar > things.. :-) kenjiro's code is order of magniture better, really. Mine was just the result of a day or two playing with fair queueing. > 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. cheers luigi 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?199804240548.HAA20491>