From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 20:19:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A5A416A4CE; Tue, 12 Oct 2004 20:19:46 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F8ED43D1D; Tue, 12 Oct 2004 20:19:46 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.93] ([66.127.85.93]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i9CKJjWi098414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2004 13:19:45 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <416C3C77.20406@errno.com> Date: Tue, 12 Oct 2004 13:20:07 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <9256D57F598E6C41B288AA7DB94F29C902DFB963@pgnmail1.pgnaplikace.cz> <20041012140205.GD29433@cell.sick.ru> <416BFE30.2090308@errno.com> <20041012185129.GA86935@ip.net.ua> In-Reply-To: <20041012185129.GA86935@ip.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Gleb Smirnoff cc: freebsd-current@freebsd.org Subject: Re: Broadcom bge and 802.1Q vlan tags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 20:19:46 -0000 Ruslan Ermilov wrote: > On Tue, Oct 12, 2004 at 08:54:24AM -0700, Sam Leffler wrote: > >>Gleb Smirnoff wrote: >> >>>On Tue, Oct 12, 2004 at 10:36:27AM +0200, Roub?cek Zdenek (T-Systems >>>PragoNet) wrote: >>>R> I have run into a problem with my Broadcom NIC (Dell LATITUDE D600). I >>>am not able to detect 802.1Q tags on incoming interface with ethereal or >>>tcpdump. All incoming packets seems like they are not coming through trunk >>>but as native ETH frames, ie. the vlan tag is missing, probably removed >>>before being passed to tcpdump? >>>R> >>>R> No I have not tested NIC's behaviour on 4.X, but I is working with >>>linux (2.6.something kernel probably?) >>>R> >>>R> Any ideas what to modify or set so I can detect vlan_tag would be very >>>apreciated. >>> >>>As Ruslan already mentioned, it is impossible to turn off hardware VLAN >>>stripping in bge driver. >>> >>>A patch to stop tagged frames to come on trunk interface is like this: >>> >>>@@ -701,13 +657,16 @@ >>> * see if the device performed the decapsulation and >>> * provided us with the tag. >>> */ >>>- if (ifp->if_nvlans && >>>- m_tag_locate(m, MTAG_VLAN, MTAG_VLAN_TAG, NULL) != NULL) { >>>+ if (m_tag_locate(m, MTAG_VLAN, MTAG_VLAN_TAG, NULL) != NULL) { >>> /* >>> * vlan_input() will either recursively call ether_input() >>> * or drop the packet. >>> */ >>>- KASSERT(vlan_input_p != NULL,("ether_input: VLAN not >>>loaded!")); >>>+ if (vlan_input_p == NULL) { >>>+ /* vlan(4) is not loaded, discard frame */ >>>+ m_freem(m); >>>+ return; >>>+ } >>> (*vlan_input_p)(ifp, m); >>> return; >>> } >>> >> >>This pessimizes normal traffic. >> > > m_tag_locate() doesn't look like a very expensive function. And > with the "normal traffic", I don't expect to be more than one tag, > no? Also, if if_nvlans > 0, this is already "pessimized". > > >>We should look for a solution in the >>driver(s) to avoid sending packets up with tags when no vlans are >>configured. >> > > I'd be opposed to such a change in behavior. The VLAN consumer can > be not only vlan(4), it can equally be the ng_vlan(4) node, etc. I'm not sure what you are opposed to or why. The issue I have is that m_tag_locate can be expensive if many packets have tags. The check for the existence of vlans configured on the interface short-circuits this work. That vlan-tagged packets may be generated when no vlans are configured seems wrong to me and breaks the assumption used to write the code. Changing the driver to drop the frame if ifp->if_nvlans is zero seems straightforward and could probably be hidden in the existing macro. Sam