From owner-freebsd-current@FreeBSD.ORG Wed Jun 11 16:52:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA021065673 for ; Wed, 11 Jun 2008 16:52:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4348FC17 for ; Wed, 11 Jun 2008 16:52:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id p76so1475090pyb.10 for ; Wed, 11 Jun 2008 09:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4CZz+RjpATxrplvNyIDq0c/BsrSqyJxtDzH1/elFkcE=; b=j/BdZ0aTo09vrD2INYsCBuVOxdHZfRSiBgzzc7jtPM5njjZj2QfJlu0Kq9Yyjdugk2 F1IwMEM1ht3Tl7Kcjb1qDp+xGYqYMSV39E+Qzc61q2uCFaku9P30dtKotxSikb5PLCcF PS4WLIQoPCZbNsK/Loq6n+PWsZxy3DQyF8k9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hWXuYB8G5lFCkHy9KJj+ECuRWL3C/6m2+qPolU8nAbvPNctvTlQIOyBR47fj2zUmFL SIeBub6K/xWO96NrvnOUFQ8ZhAlBIkSbKjBdP8AIeDlT2L0G7/lfejg3wuw3uPl5iGNA tErC8neptakdX2lYccZgeVdEUUMp1x4xk+8x4= Received: by 10.114.132.5 with SMTP id f5mr16189wad.201.1213203144069; Wed, 11 Jun 2008 09:52:24 -0700 (PDT) Received: by 10.114.174.13 with HTTP; Wed, 11 Jun 2008 09:52:23 -0700 (PDT) Message-ID: <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> Date: Wed, 11 Jun 2008 09:52:23 -0700 From: "Jack Vogel" To: pyunyh@gmail.com In-Reply-To: <20080611073313.GF3529@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> Cc: "freebsd-net@freebsd.org" , FreeBSD Current , FreeBSD Stable List Subject: Re: Vlan EVENT patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2008 16:52:25 -0000 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? 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. Cheers, Jack