From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 12:09:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 180D416A41C for ; Tue, 28 Jun 2005 12:09:27 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A86143D48 for ; Tue, 28 Jun 2005 12:09:26 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E06D.dip.t-dialin.net [84.163.224.109] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML29c-1DnEu51KnN-0007QA; Tue, 28 Jun 2005 14:09:25 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Tue, 28 Jun 2005 14:09:17 +0200 User-Agent: KMail/1.8 References: <42C0DB3B.6000606@elischer.org> <200506281238.04373.max@love2party.net> <200506281310.12252.net@dino.sk> In-Reply-To: <200506281310.12252.net@dino.sk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5162564.44lElaTRla"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506281409.23885.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Milan Obuch Subject: Re: Julian's netowrking challenge 2005 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2005 12:09:27 -0000 --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--