kern/94182: altq support for vlan driver

[Gleb Smirnoff]

The following reply was made to PR kern/94182; it has been noted by GNATS.

From: Gleb Smirnoff <glebius at FreeBSD.org>
To: Emil Cazamir <enterco at yahoo.com>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/94182: altq support for vlan driver
Date: Mon, 27 Mar 2006 11:11:20 +0400

 On Sun, Mar 26, 2006 at 11:22:54AM -0800, Emil Cazamir wrote:
 E> I see that the only way to work this out is the following:
 E> - I upgrade the system to RELENG-6 or newer (altq has support for bge driver)
 E> - I will attempt to use some undocumented option of pf: packet matching for any ethertype
 E> - I make use of ipfw's packet matching code to enqueue traffic (ipfw can either see "from any to any via vlanX" or at least "from any to any mactype vlan"
 E> - I will make more complicated my configuration scripts
 E> 
 E> Problems which will remain open:
 E> - pf.conf manual page, which doesn't state that how to match packets with ethertype = 802.1Q (it only states that matching is "based on attributes of their layer 3 headers" is outdated. This makes pf integration to FreeBSD to appear as being in beta stage. 
 E> - A simple packet matching and enqueueing rule such as "pass out on vlan1 inet from any to some.ip.add.ress queue vlan1_queue1_out" can be defined only with a stranger form such as: "pass out on vlan1 inet from any to some.ip.add.ress queue bge0_q1" and i see this a little weird. 
 
 I don't see this weird.
 
 E> - For most unexperienced users (and not only for them), an attempt to use a ruleset which looks  OK, and is working fine with physical-only interfaces, can lead to unexpected results. In the following situation: bge0 is the parent of vlan0:
 E> pass out on vlan0 all queue q_egress_1
 E> pass in   on vlan0 all
 E> block on bge0 all
 E> In the above situation a packet which should pass through vlan0 will be blocked by the rule below (not tested, but considering that pf inspects at layer3 address..), and with ipfw this won't happen (neither tested :)). This require a special section on pf.conf man page, to make the users aware of such situations.
 
 I'm not sure, but I think, that the traffic will not be blocked in the above
 ruleset. Please try it and see.
 
 E> - there is no way to make use of different traffic classifiers on a physical interface with more vlan sub-interfaces
 E> - there is only one default queue on a phisical interface, and it is useful to have one default queue per logical interface.
 
 And this is correct. There is no reason to make a queue in a random place in the
 kernel. The queue is made in a place where CPU is waiting for something to complete,
 usually I/O. We can wait for NIC to transmit, or for HDD to write data. What for do
 we wait in vlan(4) driver? Nothing. We enqueue and then dequeue, just wasting CPU
 cycles.
 
 E> Some workarounds for the performance impact you mentioned could be some definition in the kernel configuration file, which should be a trigger for "vlan enhanced performance code", and it's up to FreeBSD's core team whether this should be enabled by default or not. From my point of wiew, this  "vlan enhanced code" should be enabled for those who need it: (multi)GB_ethernet_routers_administrators, long_firewall_ruleset_users, etc.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE