From owner-freebsd-net@FreeBSD.ORG Thu Jun 12 02:41:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73BB0106566B for ; Thu, 12 Jun 2008 02:41:40 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1FEA38FC2B for ; Thu, 12 Jun 2008 02:41:39 +0000 (UTC) (envelope-from sam@errno.com) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m5C2GeWC004505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2008 19:16:40 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <48508708.50903@errno.com> Date: Wed, 11 Jun 2008 19:16:40 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: pyunyh@gmail.com References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> In-Reply-To: <20080612000943.GA7250@cdnetworks.co.kr> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: Vlan EVENT patch 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: Thu, 12 Jun 2008 02:41:40 -0000 [trimming cc list to reduce spamage] Pyun YongHyeon wrote: > On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: > > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon wrote: > > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > > > This is a small patch that Sam came up with for me, it will allow > > > > drivers to know > > > > when a vlan attaches. > > > > > > > > It is transparent to any code that doesn't want to change, but this > > > > will allow my > > > > drivers to finally utilize the vlan hardware filter (something Linux has had for > > > > ever but we lacked). > > > > > > > > > > Just curious, is there any rule how to use that new capability? > > > Because drivers will receive events whenever VLAN tags are > > > added/removed they would know how to act for these events. If > > > promiscuous mode is on for interface, driver should not filter any > > > VLAN tagged frames, right? > > > If users want to disable VLAN hardware filtering feature what is > > > best way to perform this? Introducing a new flag like > > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > > > I guess VIA Rhine III also have VLAN hardware filtering capability > > > so it would be even better if we have a way to share common part. > > > > All the patch does is have the vlan driver generate events when it attaches > > or detaches from a NIC, there are no rules, however I can tell you what > > I'm coding into this in the Intel drivers. > > > > The way it works is the driver registers a callback for each event, I will > > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. > > > > Right now, the drivers just generically enable VLAN capability because > > there is never a trigger to know IF and WHEN you need to do so, but > > with this change the VLAN capability will only get turned on by the > > registration routine. > > > > Most significantly, now when the pseudo device it gives the driver > > the VLAN tag, this will mean the driver will be able from the start > > to use the VFTA, the hardware filter, for each vlan attach the driver > > will add the ID into this table. > > > > The unregister event will turn the table entry off, and if this is the > > last VLAN being detached it will then disable the features. > > > > Oh yes, these routines will also take care of the size change of > > the frame due to the tag. I already have the changes in place in > > the igb drive, and they are working great. > > > > I do not understand why you think you need a flag to disable this, > > yes it could be done, but why? If you need to do some sort of > > debugging won't a system not using vlans and in promiscuous > > mode do just fine? > > > > I guess this would be the same reason why FreeBSD have a way to > disable checksum offload for buggy hardware. Diabling all hardware > VLAN assistance due to broken VLAN filtering doesn't look right. > > > It just seems to violate the whole reason for doing vlans in the > > first place, however perhaps I am missing something? I do not > > believe the Linux driver has some way to disable use of the table > > but I'll double check on that. > > > > Remember, this change requires NO driver changes unless they > > wish to take advantage of the ability. > > Yes. > > > > > Cheers, > > > > Jack > > Thanks. Sounds like there needs to be a h/w vlan assist capability bit that controls this in the driver. Then you'd have a way to disable via ifconfig w/ a trivial mod. Sam