From owner-freebsd-bugs@FreeBSD.ORG Mon Mar 27 07:20:16 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B697916A41F for ; Mon, 27 Mar 2006 07:20:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42D5443D45 for ; Mon, 27 Mar 2006 07:20:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2R7KGAL047068 for ; Mon, 27 Mar 2006 07:20:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2R7KG5P047067; Mon, 27 Mar 2006 07:20:16 GMT (envelope-from gnats) Date: Mon, 27 Mar 2006 07:20:16 GMT Message-Id: <200603270720.k2R7KG5P047067@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/94182: altq support for vlan driver X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 07:20:16 -0000 The following reply was made to PR kern/94182; it has been noted by GNATS. From: Gleb Smirnoff To: Emil Cazamir Cc: bug-followup@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