From owner-freebsd-net@FreeBSD.ORG Sun Feb 11 13:56:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F2B216A401; Sun, 11 Feb 2007 13:56:10 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 30EB713C474; Sun, 11 Feb 2007 13:56:10 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 0EF0E1AA29B; Sun, 11 Feb 2007 08:56:08 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sun, 11 Feb 2007 08:56:08 -0500 X-Sasl-enc: I3KE1qwZsxpTxlLur0gCD0fgKAVWjGpxXJda9ldv+w2h 1171202167 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 861169409; Sun, 11 Feb 2007 08:56:07 -0500 (EST) Message-ID: <45CF2077.1060106@FreeBSD.org> Date: Sun, 11 Feb 2007 13:56:07 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Andrew Thompson References: <45CDFA18.3030102@incunabulum.net> <45CE0ED9.1010905@FreeBSD.org> <20070211062148.GA33021@heff.fud.org.nz> In-Reply-To: <20070211062148.GA33021@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Part 2 of low level 802.1p priority support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2007 13:56:10 -0000 Andrew Thompson wrote: > This is great for the bridge, it has needed to take the vlan tag into > account when deciding to forward or not. Having m_pkthdr.ether_vtag > always set makes this much easier to implement. > > In the deleted code M_VLANTAG is cleared but is not done anymore, is > this right? > Correct. The vlan(4) code as it currently stands consumes M_VLANTAG (though as its allocation has been moved into the mbuf header itself, there is no additional free needed -- it's not a deep allocation). The patch moves the M_VLANTAG handling into ether_demux() (it should probably move further down to ether_input()) and always sets M_VLANTAG if we got raw 802.1q frames from the NIC (!(ifcap & VLAN_HWTAG) situation), so that we can deal with VLAN 0 in a clean way in ether_demux(). This may be a slight pessimization, but we always knew that cards which don't deal with 802.1q in hardware cause a performance hit anyway -- this just means that they will at least be able to process packet priorities! M_VLANTAG then may be passed to upper layers, providing they either ignore its presence or do something useful with it. In the case of ALTQ we'd examine the priority field in the 802.1q tag to map Layer 2 Quality of Service to ALTQ rules. These changes really need to be considered together with M_PROMISC. NetBSD did this presumably to stop the madness we have in ether_demux() to deal with the situation of stacked software Ethernet devices (vlan, bridge, agr, etc); M_PROMISC gets set for frames coming in off the card which we wouldn't have received had we not been in IFF_PROMISC. 'I am a hub, not a switch'. It's not smart enough to drop M_MCASTs we didn't ask for, it will blindly tag those also. Both of these changes use mbuf flags, not tags, because tags have a higher cost. M_PROMISC is also used in NetBSD to stop the IP forwarding paths seeing promiscuous traffic. Throw a wi(4) PRISM2 card into a laptop and set up OSPF+DVMRP on the same FreeBSD kernel and you'll see what I mean. We have checks in our code which only deal with that if there's a vlan(4) configured on top of your NIC... BMS