Date: Tue, 28 Jun 2005 14:09:17 +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: <200506281409.23885.max@love2party.net> In-Reply-To: <200506281310.12252.net@dino.sk> References: <42C0DB3B.6000606@elischer.org> <200506281238.04373.max@love2party.net> <200506281310.12252.net@dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart5162564.44lElaTRla Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 28 June 2005 13:10, Milan Obuch wrote: > On Tuesday 28 June 2005 12:37, Max Laier wrote: > > On Tuesday 28 June 2005 12:27, Jeremie Le Hen wrote: > > > > Wouldn't a more general approach be better. e.g. a way to "tag" a > > > > packet before it is sent to divert and a matching tag-lookup that c= an > > > > do further action. This would make it very easy to do all kinds of > > > > stuff that needs to know the original address instead of the > > > > translated one while avoiding code duplication. > > > > > > Having the possibility to tag a packet would be worth indeed. But I > > > think that Milan wants to bring network stack virtualization in > > > newer release of FreeBSD IIUC. This would be, IMO, a great improveme= nt > > > of FreeBSD networking, although I'm pretty sure this would make > > > Netgraph people react a bit ;-). > > > > Stack virtualization is independent of this. All I am trying to say > > here, is that I think it is better to have a general mechanism to do > > thing like that, instead of a special solution for fwd (i.e. > > set-nexthop). > > We agree on this. Tagging and virtualization are independent and solve > different purposes. My reaction was to post mentioning request caused from > various limitations/deficiences, namely lack of multiple routing tables > support. > > > > > 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= =20 bitfield and maybe a 32Bit cookie might be useful, but there are tradoffs t= o=20 consider: Dragonfly did extend the pkthdr to pack all the possible pf mbuf= =20 tags inside it. This adds 12 byte at the moment. As a consequence it=20 decreases the datasize in presence of a pkthdr by 12 byte. With an MSIZE o= f=20 256 this means you can have 219 (32bit pointer/int) / 195 (64bit pointer/in= t)=20 byte in a packet before you need to create an mbuf cluster. With FreeBSD=20 (also using MSIZE of 256) this is 231 / 207 - one has to carefully look at= =20 mean packet sizes to evaluate if this is a tradeoff that is worth paying. = =20 Keep in mind that not everybody does packet filtering and might just need r= aw=20 packet pushing performace (i.e. wants to avoid mbuf clusters for small=20 packets at any cost). On the other hand a zone allocator for mbuf tags might be the right solluti= on=20 here? =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 --nextPart5162564.44lElaTRla Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCwT3zXyyEoT62BG0RAqg/AJ9vEy1H16eVy0rg2xS7j4fgV007/ACfba6D vUSVgMMWMLPaFURYTGEgx2o= =3wD3 -----END PGP SIGNATURE----- --nextPart5162564.44lElaTRla--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506281409.23885.max>