From owner-freebsd-net@FreeBSD.ORG Thu Jun 12 04:07:04 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 EC97A1065679 for ; Thu, 12 Jun 2008 04:07:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id AB3408FC14 for ; Thu, 12 Jun 2008 04:07:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4128133rvf.43 for ; Wed, 11 Jun 2008 21:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wgoEYaIuQaaDQbmcAoKUJALlBolXjKOV3XN43o6oTrY=; b=QKcp6BuumVMni+cYU75Ga5BoPFMyFEwuvuKdv5TUzP1hVOVKWXq0F5gxPX0ua/1ueQ k2ZCaqxjuVu9C6Bw/Amn6A8lDgN7jYam8/OA1AVAIpBqibWIrm8ikiNP7QZe19uH5uBI nc2AukQjc/KCCIQbdIOVdCGbiNsKD3/u53Wl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=kMsguQmUAQP2BHTtVcHvzXme/FoQyTrULrtnmPqe03hPiwdAwUQ1aXTeTLO9X91TLS sDEqUUNsV8Pzfg02hTJvYJdi7xaMWylZ1kft/Y1nG9ajzC8staYy4MhVEUyYOtANKudA esfPKHH54K9irQsbhfrby1YuHG7pEDyVU3Yb8= Received: by 10.140.131.11 with SMTP id e11mr506011rvd.234.1213243623109; Wed, 11 Jun 2008 21:07:03 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id f21sm984146rvb.0.2008.06.11.21.07.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Jun 2008 21:07:02 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m5C44rFZ008103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 13:04:53 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m5C44q48008102; Thu, 12 Jun 2008 13:04:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 12 Jun 2008 13:04:52 +0900 From: Pyun YongHyeon To: Jack Vogel Message-ID: <20080612040452.GE7250@cdnetworks.co.kr> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> <48508708.50903@errno.com> <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: "freebsd-net@freebsd.org" Subject: Re: Vlan EVENT patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com 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 04:07:04 -0000 On Wed, Jun 11, 2008 at 08:48:58PM -0700, Jack Vogel wrote: > On Wed, Jun 11, 2008 at 7:16 PM, Sam Leffler wrote: > > [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. > > I don't want to create stuff in ifconfig when I'm not convinced > of the need. If there were, as he says, 'buggy hardware', specifically > buggy Intel hardware, then either our drivers would have had special > errata or workarounds in it for that, but none of the OS drivers have > any special code for issues involving VFTA (the filter) or other VLAN > controlling components that I am aware of. > > If there are other network drivers that are buggy in this regard then why > encumber the generic interface due to that, let the drivers deal with it, > via sysctl or something of the sort. > > There are enough real cases of hardware problems we need to address in > code that I don't just want to modify code on the mere theoretical possibility > of such. > > How bout this, we put the change into HEAD, I add support as I've planned into > the em and igb drivers, and then we let them get tested, if a real problem comes > up, THEN we worry about adding special case code, how's that? > Please go ahead. I don't have any objections on it. I just thought it would be better to show a flag to indicate hardware VLAN filtering is active in ifconfig(8) and have user disable this feature in some rare cases. > Regards, > > Jack -- Regards, Pyun YongHyeon