Date: Tue, 28 Jun 2005 14:37:05 +0200 From: Max Laier <max@love2party.net> To: freebsd-net@freebsd.org Cc: Milan Obuch <net@dino.sk> Subject: Re: Julian's netowrking challenge 2005 Message-ID: <200506281437.11835.max@love2party.net> In-Reply-To: <200506281415.36453.net@dino.sk> References: <42C0DB3B.6000606@elischer.org> <200506281409.23885.max@love2party.net> <200506281415.36453.net@dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart4196071.KaRSGDIm1S Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 28 June 2005 14:15, Milan Obuch wrote: > 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.=20 > > > > The downside of this approach is that you need to malloc the tag, b= ut > > > > 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 a= nd > > > > 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.= =20 > > 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 :) The problem here is that this has to be a static thing (otherwise you need = an=20 additional malloc and your possible performance gain is lost). If you chan= ge=20 MSIZE or sizeof(struct pkthdr) on a kernel option, you will have to recompi= le=20 all network device drivers and everything else that touches mbufs. This wi= ll=20 effectively prevent the use of 3rd party drivers. So it has to be one size= =20 fits all, which is - most likely - the minimal version pkthdr and additiona= l=20 mallocs when needed. > > 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 :)] See zone(9) for details. Basically we would have a cache of mbuf tags that= =20 get reused, thus taking of pressure off the rest of the memory management=20 system. Again we have to evaluate carefully if that is actually a=20 performance gain or hit - though I certainly suspect a gain. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4196071.KaRSGDIm1S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCwUR3XyyEoT62BG0RApT+AJ41UAdIIUbh4v6RsO37yzXmDhKq6wCfbwI1 AzqvdrBQ6RwhUSVkaV9Y9SQ= =pTEM -----END PGP SIGNATURE----- --nextPart4196071.KaRSGDIm1S--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506281437.11835.max>