Date: Wed, 2 May 2001 11:32:53 +0200 From: "Fulvio Risso" <risso@polito.it> To: "Casper Dik" <Casper.Dik@Sun.COM>, "Darren Reed" <darrenr@reed.wattle.id.au> Cc: "Gunther Schadow" <gunther@aurora.regenstrief.org>, <snap-users@kame.net>, <freebsd-net@freebsd.org>, <ipfilter@coombs.anu.edu.au>, <altq@csl.sony.co.jp> Subject: RE: [altq 829] Re: The future of ALTQ, IPsec & IPFILTER playing together ... Message-ID: <DAEBKLBDIOIBBIFCOHNKMEDODLAA.risso@polito.it> In-Reply-To: <200105020736.JAA16563@romulus.Holland.Sun.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-altq@csl.sony.co.jp [mailto:owner-altq@csl.sony.co.jp]On > Behalf Of Casper Dik > Sent: Wednesday, May 02, 2001 09:37 > To: Darren Reed > Cc: Gunther Schadow; snap-users@kame.net; freebsd-net@freebsd.org; > ipfilter@coombs.anu.edu.au; altq@csl.sony.co.jp > Subject: [altq 829] Re: The future of ALTQ, IPsec & IPFILTER playing > together ... > > > > >BPF uses a byte-code language, like Java, to tell the > >matching routine what bits to compare and return a "true or > >false". i.e. you need to build things around it if you want > >to use it for packet matching, etc. > > > BPF doesn't seem to lend itself to "keeping state" either. It's a > packet filtering language that has no provisions for keeping external > state, AFAIK. Just because the 4K memory is allocated on a per-packet basis. Checking at the BPF source code I think it's not a big issue to allocate the memory *once* at the beginning of the capture, and use it to store intermediate results. However, as far as I know, also MPF guys choose to use a distinct set of memory to store intermediate results. Cheers, fulvio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DAEBKLBDIOIBBIFCOHNKMEDODLAA.risso>