* Johan Beisser <j...@caustic.org> [2013-10-16 21:09]: > Right. I guess if I want to define multiple queues for matching > traffic, I need to either redo the filter rules to use tagging*, or > simply do it per outbound bit of traffic.
let's make that outright clear: defining queues is for bandwidth shaping only. there is no need (or sense) to do so for prio queueing. prio queueing is ALWAYS there & on for a couple of releases now, and some things like carp announcements are priorized by default. there is nothing to configure for prio queueing (why should there), every ifqueue, be it on an interface or elsewhere, e. g. ipintrq, has 8 sub-queues that are processed in order at dequeue time. for the new bandwidth shaping subsystem, it is rather more powerful than altq, unless you were one of the extremely rare ones that figured out hfsc in altq. cbq is gone & dead, it doesn't make any sense any more since it can entirely be expressed in hfsc. Someone asked about borrowing: there is always borrowing, up to the bw specified with "max". the newqueue commits included one to pf.conf.5, and I think the QUEUEING section is pretty clear. More background can be found in my presentation on the topic at http://bulabula.org/papers/2012/eurobsdcon/ What is missing now is RED. Aside and as said before I'd like to change hfsc itself so that we can queue in any queue and not just leaf queues, that would allow for much more flexibility. That's a change to the algorithm itself tho and everything but trivial (kudos if someone beats me to do it). ALTQ was super important at its time, when bandwidth shaping and the like were rather new and there was a lot of research going on. That is what ALTQ was written for, and it is a major reason for there being a sound understanding of queueing effects now - and that's why altq has pluggable schedulers (different queueing algorithms), so many buttons and options: research. To get people an idea: the altq core alone is over 7000 lines of code, and that's without the hooks into the rest of the kernel, without the userland bits, and without documentation - that roughly doubles that number. In contrast, the entire newqueue _diff_ (larger due to context!): 4423 newqueue.diff to be fair, that's without prio queueing, but the entire prio queueing stuff must be well under a thousand loc - prio queueing is rather simple. As said before, I plan to remove altq after the 5.5 release, so that release will have both and people have time to migrate. I won't do such a huge parallel-backwards-compat circus again, it has been a nightmare. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
