Date: Thu, 30 Sep 2004 06:53:47 +0200 From: Max Laier <max@love2party.net> To: freebsd-ipfw@freebsd.org Subject: Re: ALTQ with IPFW Message-ID: <200409300653.56969.max@love2party.net> In-Reply-To: <cone.1096495617.888686.641.1001@phobos.totalterror.net> References: <20040929195920.GC1807@green.homeunix.org> <cone.1096495617.888686.641.1001@phobos.totalterror.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart6727800.5apvD9GZZW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 30 September 2004 00:06, Niki Denev wrote: > Brian Fundakowski Feldman writes: > > Since I've seen some desire for ALTQ support for IPFW, and I've > > personally been interested in using the more complex traffic shaping > > topology that it provides, I decided to go ahead and get it working. I > > had to use mlaier's un-committed dc(4) ALTQ support, too, which seems to > > work. The ipfw(8) program now queries pf(4) for ALTQ queue id <-> queue > > name translation, so you would first use pfctl(8) to set up the queues > > before adding IPFW "altq" rules. Brian, can you go ahead and take care of the dc(4) modification if it prove= s=20 stable for you? That'd be great. > This sounds pretty cool! :) Indeed it does, though I hope we can find time sometime to overhaul the ALT= Q=20 configuration API in a way that makes things like that nice and easy. > /offtopic > This reminds me that i was thinking from some time that > it will be really nice if pf could be used as a packet > classifier for DUMMYNET. > What do you think about that? Not much. When Andre did the ipfw -> pfil change we discussed this topic an= d=20 decided that dummynet does not fit to pf very much, at this point. I will b= e=20 looking into divert sockets for pf before considering dummynet. And even fo= r=20 divert sockets I have mixed feelings. We'll see what 6-CURRENT brings ;-) In any case this would involve a very extensive reorganization of how dummy= net=20 is hooked into the processing path and handles arguments etc. ... this is=20 hard and unthankful work. Feel free to submit patches ;-) > And since we are here, i want to ask one more thing, > that bothers me from some time. > I'm using pf on FreeBSD and on pf+altq on OpenBSD machines. > But on OpenBSD altq has limitation on the smallest bandwidth that i can > shape, it was 5.6Kbits as far as i remember. > This limitation was explained by the timer resolution. > So what is the situation in FreeBSD, as it can be compiled with higher > resolution, i.e. HZ=3D1000 or more? (or i'm mistaking something here) If you are thinking of the same thing I am (and if I remember correctly), t= his=20 is a general INT_MAX overflow protection and has nothing to do with the tim= er=20 resolution the kernel is able to provide. =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 --nextPart6727800.5apvD9GZZW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBW5FkXyyEoT62BG0RAmn+AJ9+RhssvG4231AP/NzYrg4gSwXDvwCfUOWK +NFFjr4vkAknzAXl46GEPOU= =dC0w -----END PGP SIGNATURE----- --nextPart6727800.5apvD9GZZW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409300653.56969.max>