ALTQ with IPFW

Max Laier max at love2party.net
Wed Sep 29 21:56:43 PDT 2004


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 proves 
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 ALTQ 
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 and 
decided that dummynet does not fit to pf very much, at this point. I will be 
looking into divert sockets for pf before considering dummynet. And even for 
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 dummynet 
is hooked into the processing path and handles arguments etc. ... this is 
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=1000 or more? (or i'm mistaking something here)

If you are thinking of the same thing I am (and if I remember correctly), this 
is a general INT_MAX overflow protection and has nothing to do with the timer 
resolution the kernel is able to provide.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20040930/4d5ffafd/attachment.bin


More information about the freebsd-ipfw mailing list