From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 15:44:19 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 9051016A4CF; Wed, 13 Oct 2004 15:44:19 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23F4643D4C; Wed, 13 Oct 2004 15:44:19 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i9DFiIWi003003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2004 08:44:18 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <416D4EE6.1080109@errno.com> Date: Wed, 13 Oct 2004 08:51:02 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 0.7.3 (X11/20041009) 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> <416C3C77.20406@errno.com> <20041013064227.GA1338@ip.net.ua> In-Reply-To: <20041013064227.GA1338@ip.net.ua> Content-Type: text/plain; charset=us-ascii; 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: Wed, 13 Oct 2004 15:44:19 -0000 Ruslan Ermilov wrote: > Hi Sam, > > On Tue, Oct 12, 2004 at 01:20:07PM -0700, Sam Leffler wrote: > >>>>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. >> > > Please take a moment and re-read what I've already said: vlan(4) is not > the only consumer of VLAN frames: ng_vlan(4) is another such one, and I > have a proprietary Netgraph node here that demultiplexes VLANs. If you > start dropping VLAN frames in drivers when if_nvlans == 0, this will be > a problem for me. Is that clear now? > > > Cheers, I've read what you've written but you also haven't explained why you can't signal the presence of these other entities in some way. The current mechanism to signal the presence of "interested parties" for vlan-tagged frames is ifp->if_nvlans. You are saying you have new (proprietary) code that is interested in vlans but will not use the existing mechanism. My reaction is fix your code, don't pessimize the code everyone else uses without netgraph. Sam