Date: Tue, 28 Jun 2005 14:15:34 +0200 From: Milan Obuch <net@dino.sk> To: freebsd-net@freebsd.org Subject: Re: Julian's netowrking challenge 2005 Message-ID: <200506281415.36453.net@dino.sk> In-Reply-To: <200506281409.23885.max@love2party.net> References: <42C0DB3B.6000606@elischer.org> <200506281310.12252.net@dino.sk> <200506281409.23885.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 June 2005 14:09, Max Laier wrote: ... > > > > > pf does something along these lines in case you are looking for > > > > > references. > > > > > > > > Would it be possible to share this tag among pf and ipfw ? > > > > > > Sure, it's a simple mbuf tag with a (at this point) 16bit cookie. The > > > downside of this approach is that you need to malloc the tag, but on > > > the other hand it's even more complicated for set-nexthop where you > > > need to allocate a route and maybe even hold it for some time and make > > > sure you properly GC it ... tags seem way simpler to me. > > > > Agreed. I am far from being networking code guru, so maybe this question > > sounds stupid, but could not this cookie be allocated when packet enters > > system? Maybe optionally... > > We could always extend the pkthdr to hold more information. An additional > bitfield and maybe a 32Bit cookie might be useful, but there are tradoffs > to consider: Dragonfly did extend the pkthdr to pack all the possible pf > mbuf tags inside it. This adds 12 byte at the moment. As a consequence it > decreases the datasize in presence of a pkthdr by 12 byte. With an MSIZE > of 256 this means you can have 219 (32bit pointer/int) / 195 (64bit > pointer/int) byte in a packet before you need to create an mbuf cluster. > With FreeBSD (also using MSIZE of 256) this is 231 / 207 - one has to > carefully look at mean packet sizes to evaluate if this is a tradeoff that > is worth paying. Keep in mind that not everybody does packet filtering and > might just need raw packet pushing performace (i.e. wants to avoid mbuf > clusters for small packets at any cost). > Well, that's why I said optionally. The question remains how this option should be turned on. We need some evaluation on this option - now it is just a guess. After some benchmarking on both approaches we could build an educated guess :) > On the other hand a zone allocator for mbuf tags might be the right > sollution here? [This space left for those understanding this issue at least a bit :)] Milan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506281415.36453.net>