I believe the solution is not patching ALTQ to the VLAN driver, but rather make ALTQ recognize rules that classify according to fields in Layer 2 header (fields such as VLANid and Priority, other than just src/dst addr/port and protocol in IP header). For example, build filter rules that specify priority tracking according to the 3-bit field in the VLAN tag as per 802.1p. For example in /etc/altq.conf: interface vx0 bandwidth 100M cbq class cbq vx0 root_class NULL pbandwidth 100 class cbq vx0 vlan1_class root_class pbandwidth 80 filter vx0 cs1_class vlan1_class vlanprio 6 # priority 6 takes more bandwidth class cbq vx0 vlan2_class root_class pbandwidth 15 filter vx0 cs2_class vlan2_class vlanprio 4 # priority 4 takes less bandwidth The discussion (patch) back then is good for a FreeBSD configured as end-host, but not as a MAC bridge: [1]http://lists.freebsd.org/pipermail/freebsd-net/2005-January/006240. html Regards, Gilbert Tsang. Max Laier wrote:
On Sunday 13 February 2005 22:36, David Gilbert wrote: Has anyone considered patching the vlan driver to support altq? I gather that since tun works, so should vlan. This should be a FAQ. Anyway, here is the story: While you can do ALTQ queueing on vlan interfaces the usefulness of this is very little. If the physical interface supports ALTQ it is *always* better to do the queueing there. If the physical interface does not support ALTQ it must be patched. [snipped] References 1. http://lists.freebsd.org/pipermail/freebsd-net/2005-January/006240.html _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"