Date: Wed, 22 Dec 2010 08:54:55 -0800 From: "Ricky Charlet" <RCharlet@adaranet.com> To: "'Spenst, Aleksej'" <Aleksej.Spenst@harman.com>, "'freebsd-pf@freebsd.org'" <freebsd-pf@freebsd.org> Subject: RE: why ALTQ must be supported by interface drivers? Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com> In-Reply-To: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com> References: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Aleksej, I happen to have recently been 'playing' with altq and trying to (s= uccessfully eventually) get to work well in the 100Mb utilization range. So you need to think of it like this, AltQ is replacing a current q= ueueing system... that of the driver. Each driver has a simple FIFO queue. = AltQ is just a more sophisticated queue for the driver to use when sending = out packets (enforcement). If, in-fact, a driver happens to implement anoth= er queue underneath the AltQ queue (sometimes happens in sophisticated hard= ware) then this 'lower' queue will probably be a FIFO queue and may wind up= destroying the value of AltQ. Now a piece of that added sophistication is classification. Site ad= ministrators set policy on which packets are more or less preferential to d= rop during congestion. AltQ's classification is implemented via the packet-= filters. A very common use case for classification is to distinguish traffic= based on layer3 and layer4 (IP and TCP/UDP/ICMP/SCTP...) headers. However = this is not the only use case and classification based on layer2 headers sh= ould continue to be supported for those few sites that wish it. In conclusion, AltQ enforcement must be implemented at the lowest l= ayer, and AltQ classification should maintain ability to examine low level = headers even though it is much more common to examine layer3 /layer4 header= s. So much for philosophy. About compiling, yes you understood quite c= orrectly. I have found these web sites to have helpful AltQ info (in no par= ticular order): http://www.sonycsl.co.jp/~kjc/software/altq-new-design.txt http://www.sonycsl.co.jp/person/kjc/software.html#ALTQ http://www.sonycsl.co.jp/person/kjc/software/TIPS.txt http://www.openbsd.org/faq/pf/index.html http://openbsd.org/faq/pf/queueing.html http://loquefaltaba.com/documentacion/pf/en/altqintro.html http://system-tribudi.blogspot.com/2006/08/pf-hfsc-part-i.html http://www.probsd.net/pf/index.php/Hednod%27s_HFSC_explained http://www.icir.org/floyd/cbq.html --- Ricky Charlet > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd- > pf@freebsd.org] On Behalf Of Spenst, Aleksej > Sent: Wednesday, December 22, 2010 4:00 AM > To: 'freebsd-pf@freebsd.org' > Subject: why ALTQ must be supported by interface drivers? > > Hi All, > > at what network level is ALTQ (QoS) implemented? At the IP level or at > the driver level? > > I would think that all queuing functionality is probabliy working at > the IP level and should not depend on underlying interfaces. Is that > correct? If this is true, I don't understand why ALTQ must be supported > by interface drivers? If I understand it correctly: (1) the driver has > to support ALTQ. (2) the driver has to be compiled as ALTQ-aware with > some special flags. > > Thanks, > Aleksej. > > > > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC>