From owner-freebsd-net@FreeBSD.ORG Thu Jun 12 17:06:06 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 BF752106566C for ; Thu, 12 Jun 2008 17:06:06 +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 77E698FC1E for ; Thu, 12 Jun 2008 17:06:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id p76so1695336pyb.10 for ; Thu, 12 Jun 2008 10:06:05 -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=kN0U087lEn0seXfrcbeBA51tWxsbNtrWqyHu8d3xMOw=; b=X960JcUg+x5d0xLk/aG6m1H9xmCSR2ikJRTLCyyCnPSvaW36tq69iV/B1QCwCHD/3d if4BeyFm96ibo3SZbcqql002XW555kbDBTdD5nQOB42lK4xBhab1u3x1RvY+fEfLxGnN axPqQrb25atbdlPT6OOhd1ML8Wg+JjDb7Wpbc= 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=APlAfPf7yRQDqGfBTiqPvhhz1fOjYAvo/hj+OOe7VdiYm/5q4X5eJvTAkcpU05vLJW BXpVxVifp4LyY2qk7votk2zFaI7Ct5jb21EWq8AFcC90QVIsrRt/qhRbheaXg8huti9B RFmUPMPybjyZQHdBQYQ0cjxbMfajvJYePyjl4= Received: by 10.114.155.1 with SMTP id c1mr1880015wae.24.1213290365211; Thu, 12 Jun 2008 10:06:05 -0700 (PDT) Received: by 10.114.174.13 with HTTP; Thu, 12 Jun 2008 10:06:05 -0700 (PDT) Message-ID: <2a41acea0806121006r23936007x5acf1fa9e302a94d@mail.gmail.com> Date: Thu, 12 Jun 2008 10:06:05 -0700 From: "Jack Vogel" To: "CZUCZY Gergely" In-Reply-To: <20080612092621.61b44529@twoflower.in.publishing.hu> 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> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> <48508708.50903@errno.com> <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> <20080612040452.GE7250@cdnetworks.co.kr> <20080612092621.61b44529@twoflower.in.publishing.hu> Cc: pyunyh@gmail.com, "freebsd-net@freebsd.org" 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 17:06:06 -0000 On Thu, Jun 12, 2008 at 12:26 AM, CZUCZY Gergely wrote: > On Thu, 12 Jun 2008 13:04:52 +0900 > Pyun YongHyeon wrote: > >> 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 > > I don't know whether it's a policy or not in FreeBSD, but I also agree with the > opinion, that a flag should show up in the ifconfig output indicating that > hardware filtering is being done on that interface. It helps the administrator > to clarify how the hardware is working, which features of the hardware are in > use, and also, they can be disabled. > Disabling features is important. Sometimes the code is messed up, the hardware > is messed up, or neither are messed up, but they are unable to work together. > In these cases the feature could be disabled without hacking the source, which > is a clean solution. FreeBSD has design, and prefers clean solutions as I see. > I understand, that you _currently_ have no troubles and problems with your code > and hardware, but there are unforseen cases out there, lots of other hardware > then intel's, and to quote Douglas N. Adams, "expect the unexpected". > > So, it won't hurt if it shows up in ifconfig, and it can be controlled, but > definitely helps our job, the administrators'. OK, if people feel strongly about this, and someone wants to implement the code in ifconfig I'll go along with it. Jack