kern/94182: altq support for vlan driver
Emil Cazamir
enterco at yahoo.com
Thu Mar 23 18:30:39 UTC 2006
The following reply was made to PR kern/94182; it has been noted by GNATS.
From: Emil Cazamir <enterco at yahoo.com>
To: Gleb Smirnoff <glebius at FreeBSD.org>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: kern/94182: altq support for vlan driver
Date: Thu, 23 Mar 2006 10:20:44 -0800 (PST)
--0-980750068-1143138044=:59095
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Gleb Smirnoff <glebius at FreeBSD.org> wrote: 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
I believe that this opinion (ALTQ + vlan is a bad idea) somehow attempts to minimize the benefits which vlan offers, or to make things more complicate than they really are. The reason for which I made the initial request is that I want to treat a vlan interface as an interface and nothing more, making use of some uniform resource configuration technique. Until recently, I used a PC with 3 physical (1xGbE + 2xFE) interfaces to connect a network to two upstream providers. At the same time, I do ip acconting and traffic shaping with dummynet. Since recently, I can make use of vlans through one of the upstream providers, to reach another subnet under my administration. The main problem is that I'm limited only to use dummynet, and I want to use ALTQ in combination with dummynet to give to my customers more traffic options, while letting them to use more bandwidth to communicate between subnets at a higher speed.
Here's the big picture:
provider1 (vlan1)
`- | | vlan1-GbE0(myrouter)| lan#1
|802.1q switch| vlan2-GbE0(myrouter)|
,- | | --- vlan3 --- |
provider2
`- |another_802.1q_sw|vlan2|another_router | lan#2
| | --- vlan3 --- |
service type #1 (85% of all bandwidth): WF2Q+: dummynet with dynamic queues, use weighted fair all available bandwidth until they reach some byte counters.
service type #2 (15% of all bandwidth): ALTQ and cbq or hfsc with shared bandwidth between few customers with different needs.
My goal is to use dummynet and altq on vlan1, vlan2 and vlan3. Dummynet has the advantage of dynamic queues, which means that i need only one ipfw rule to do the traffic discipline with dummynet. I also have a small number of customers which want to use a service with maximum bandwidth much below to the bandwidth i offer with dummynet, but I can't use dynamic pipes with them because I won't be able to share bandwidth between them.
The main problem is that I don't have the budget to use a blade server chassis and server modules for this purpose, and I believe that until the number of customers will be below 1000 - 1500, I will be able to use a single computer for this purpose.
Best regards,
Emil Cazamir
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
--0-980750068-1143138044=:59095
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<b style="font-family: courier;"><i>Gleb Smirnoff <glebius at FreeBSD.org></i></b><span style="font-family: courier;"> wrote:</span><blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; font-family: courier;"> Emil,<br><br>On Tue, Mar 21, 2006 at 11:50:26AM -0800, Emil Cazamir wrote:<br>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 h is 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>E> - physical device:<br>E> |- vlan1 - cbq on vlan1<br>E> |- vlan2 - priq on vlan2<br>E> `- vlan3 - hfsc on vlan3<br><br>This may not work, unless you put a bandwidth limit on each vlan interface,<br>that is equal to limit of parent interface / number of vlans.<br><br>E> At this time i know that altq ca
n
make use
of only one traffic discipline on an interface, which makes the above case only a wish.<br>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-PR ERELEASE as of 2006, march 17.<br><br>The first (theoretical) obstacle is that ALTQ is designed to shape traffic on<br>an interface, where exists a *bandwidth limit* and a *queue*. These two<br>things are property of a physical inteface. The vlan(4) interface doesn't<br>have any bandwidth limit. The current implementation has a queue. Packets<br>are temporarily queued, before they are sent to the underlying physical<br>driver. We have a plan to remove this queue, since it
is
a
performance loss<br>for vlan(4) driver.<br><br>The second (practical) problem is that after removal of the intermediate<br>queue in the vlan(4) driver it will be difficult to add ALTQ support. No<br>queueing - no ALTernate Queueing.<br><br>-- <br>Totus tuus, Glebius.<br>GLEBIUS-RIPN GLEB-RIPE<br></blockquote><span style="font-family: courier;">I believe that this opinion (ALTQ + vlan is a bad idea) somehow attempts to minimize the benefits which vlan offers, or to make things more complicate than they rea lly are. The reason for which I made the initial request is that I want to treat a vlan interface as an interface and nothing more, making use of some uniform resource configuration technique. Until recently, I used a PC with 3 physical (1xGbE + 2xFE) interfaces to connect a network to two upstream providers. At the same time, I do ip acconting and traffic shaping with dummynet. Since recently, I can make use of vlans through one of the upstream providers, to reach another
s
ubnet
under my administration. The main problem is that I'm limited only to use dummynet, and I want to use ALTQ in combination with dummynet to give to my customers more traffic options, while letting them to use more bandwidth to communicate between subnets at a higher speed.</span><br style="font-family: courier;"><span style="font-family: courier;">Here's the big picture:</span><br style="font-family: courier;"><span style="font-family: courier;">provider1 (vlan1)</span><br style="font-family: courier;"><sp an style="font-family: courier;"> `- | | vlan1-GbE0(myrouter)| lan#1</span><br style="font-family: courier;"><span style="font-family: courier;"> |802.1q switch| vlan2-GbE0(myrouter)|</span><br style="font-family: courier;"><span style="font-family: courier;"> ,- | | --- vlan3 --- |<
/s
pan><br
style="font-family: courier;"><span style="font-family: courier;">provider2<br> `- |another_802.1q_sw|vlan2|another_router | lan#2<br> | | --- vlan3 --- |<br><br>service type #1 (85% of all bandwidth): WF2Q+: dummynet with dynamic queues, use weighted fair all available bandwidth until they reach some byte counters.<br>service type #2 (15% of all bandwidth): ALTQ and cbq or hfsc with shared bandwidth between few customers with different needs.<br><br>My goal is to use dummynet and altq on vlan1, vlan2 and vlan3. Dummynet has the advantage of dynamic queues, which means that i need only one ipfw rule to do the traffic discipline with dummynet. I also have a small number of customers which want to use a service with maximum bandwidth much below to the bandwidth i offer with dummynet, but I can't use dynamic pipes with them because I
w
on't be
able to share bandwidth between them.<br>The main problem is that I don't have the budget to use a blade server chassis and server modules for this purpose, and I believe that until the number of customers will be below 1000 - 1500, I will be able to use a single computer for this purpose.<br><br> <br>Best regards,<br>Emil Cazamir<br><br></span><p>
<hr size=1>Yahoo! Messenger with Voice. <a href="http://us.rd.yahoo.com/mail_us/taglines/postman1/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com">Make PC-to-Phone Calls</a> to the US (and 30+ countries) for 2¢/min or less.
--0-980750068-1143138044=:59095--
More information about the freebsd-bugs
mailing list