Date: Wed, 22 Mar 2006 11:40:14 GMT From: Gleb Smirnoff <glebius@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/94182: altq support for vlan driver Message-ID: <200603221140.k2MBeEuC090290@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/94182; it has been noted by GNATS. From: Gleb Smirnoff <glebius@FreeBSD.org> To: Emil Cazamir <enterco@yahoo.com> Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/94182: altq support for vlan driver Date: Wed, 22 Mar 2006 14:38:12 +0300 Emil, On Tue, Mar 21, 2006 at 11:50:26AM -0800, Emil Cazamir wrote: E> I'm not the person to decide if ALTQ and vlan(4) is a good or bad combination, but in my opinion it would be useful to specify each queueing strategy on his own interface, even if it is not a phisical one (such as tun(4)). A good example why vlan interfaces should be ALTQ-enabled is the following: E> - physical device: E> |- vlan1 - cbq on vlan1 E> |- vlan2 - priq on vlan2 E> `- vlan3 - hfsc on vlan3 This may not work, unless you put a bandwidth limit on each vlan interface, that is equal to limit of parent interface / number of vlans. E> At this time i know that altq can make use of only one traffic discipline on an interface, which makes the above case only a wish. E> I think if ALTQ will not be implemented as standard feature in FreeBSD, it would be nice at least to be documented the fact that ALTQ works with vlan tagged frames somewhere in the man pages (no one officialy says that it works and I didn't tested that). At this time i don't find any reference to vlan tagged frames matching with ALTQ and pf, neither in altq(4) nor pf.conf(5) man pages. I'm using FreeBSD 5.5-PRERELEASE as of 2006, march 17. The first (theoretical) obstacle is that ALTQ is designed to shape traffic on an interface, where exists a *bandwidth limit* and a *queue*. These two things are property of a physical inteface. The vlan(4) interface doesn't have any bandwidth limit. The current implementation has a queue. Packets are temporarily queued, before they are sent to the underlying physical driver. We have a plan to remove this queue, since it is a performance loss for vlan(4) driver. The second (practical) problem is that after removal of the intermediate queue in the vlan(4) driver it will be difficult to add ALTQ support. No queueing - no ALTernate Queueing. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603221140.k2MBeEuC090290>