Date: Tue, 21 Mar 2006 20:00:36 GMT From: Emil Cazamir <enterco@yahoo.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/94182: altq support for vlan driver Message-ID: <200603212000.k2LK0af8029670@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: Emil Cazamir <enterco@yahoo.com>
To: Gleb Smirnoff <glebius@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/94182: altq support for vlan driver
Date: Tue, 21 Mar 2006 11:50:26 -0800 (PST)
--0-1856313939-1142970626=:89149
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Gleb Smirnoff <glebius@FreeBSD.org> wrote: Emil,
if you search through mail archives, you will find, that the
question about ALTQ on vlan(4) was raised several times. There is
an opinion, that the idea itself is not correct at all.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
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:
- physical device:
|- vlan1 - cbq on vlan1
|- vlan2 - priq on vlan2
`- vlan3 - hfsc on vlan3
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.
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.
Best regards,
Emil Cazamir
---------------------------------
Yahoo! Travel
Find great deals to the top 10 hottest destinations!
--0-1856313939-1142970626=:89149
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<b><i>Gleb Smirnoff <glebius@FreeBSD.org></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Emil,<br><br> if you search through mail archives, you will find, that the<br>question about ALTQ on vlan(4) was raised several times. There is<br>an opinion, that the idea itself is not correct at all.<br><br>-- <br>Totus tuus, Glebius.<br>GLEBIUS-RIPN GLEB-RIPE<br></blockquote><br>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: <br>- physical device:<br> |- vlan1 - cbq on vlan1<br> |- vlan2 - priq on vlan2<br> `- vlan3 - hfsc on vlan3<br>At this time i know that altq can make use of only one traffic discipline on a
n
interface, which makes the above case only a wish.<br>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.<br><br>Best regards,<br>Emil Cazamir<br><br><p>
<hr size=1>Yahoo! Travel<br>
<a href="http://us.lrd.yahoo.com/_ylc=X3oDMTFscDlocTFiBF9TAzMyOTc1MDIEX3MDMjcxOTQ4MQRwb3MDMgRzZWMDbWFpbC1mb290ZXIEc2xrA3l0LXR0/SIG=12hqieud9/**http%3a//leisure.travelocity.com/Promotions/0,,YHOE%7c1381%7cvacs_main,00.html">Find
great deals</a> to the top 10 hottest destinations!
--0-1856313939-1142970626=:89149--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603212000.k2LK0af8029670>