On 05/08/14 10:23, Henning Brauer wrote:
* David Dahlberg <david.dahlb...@fkie.fraunhofer.de> [2014-08-05 10:17]:
Am Dienstag, den 05.08.2014, 08:36 +0200 schrieb Henning Brauer:
queueing on vlan is pretty meaningless.
however, classification can happen anywhere, so assign queues on your
vlan interface and create them on the physical one, things will Just
Work (tm).
Strangely, the following (simplified) setup seems to work here on 5.5
nevertheless:
queue vlan33q on vlan33 bandwidth 2M, max 2M
match out on vlan33 all set queue vlan33q
In "pfctl -sq" this looks exactly like I expected and it does exactly
what I intended it to do.
except that the underlaying physical if's queue destroys the effects -
not necessarily always, but most of the time.
by just chaning your queue def to
queue vlan33q on <vlan33's vlandev> bandwidth 2M, max 2M
(no, NOT literal <..>, you expand that yourself)
does what you intended in the first place.
Correct me if I'm wrong here Henning, but we have always used the
approach of only ever assigning queues to the physical interface
(whether it has VLANs or not), as this means that both the physical
interfaces untagged network, plus all the tagged networks on that
interface get to share the queues.
Having lots of physical internal interfaces with queues on each simply
means you have to divide our total WAN download bandwidth across the
interfaces as they cannot borrow from each other.
But if you use VLANS and place the queues on the physical interface, if
the public WIFI VLAN for example is not using any bandwidth, the
internal LAN can use all the bandwidth until the public WIFI wants some.
Considering all this, there should never be a good reason to apply
queues to the VLAN interfaces at all?
But as you (if anybody) indeed should known, what happens. Please tell
me, what the above config actually does. Will the first line silently
add a vlan33q to re0 that still does what it is intended?
no, it does queueing on vlan33.
but since we end up queueing the packets on vlan33's vlandev again,
the effects often just aren't there. queueing is a lot about timing...
at some point we used vlans with a queue depth of 1, since there
really is no point in queueing there at all, but that exposed some
otehr bugs. we might eventually go back to that.
