Date: Thu, 12 Jun 2008 09:26:21 +0200 From: CZUCZY Gergely <phoemix@harmless.hu> To: pyunyh@gmail.com Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Jack Vogel <jfvogel@gmail.com> Subject: Re: Vlan EVENT patch Message-ID: <20080612092621.61b44529@twoflower.in.publishing.hu> In-Reply-To: <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> <20080612040452.GE7250@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/il4TY5XZLaETCJstBMO17Lx Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 12 Jun 2008 13:04:52 +0900 Pyun YongHyeon <pyunyh@gmail.com> 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 <sam@errno.com> 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 <pyunyh@gmail.c= om> > > >> 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 (someth= ing > > >> 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 featur= e? > > >> > > I guess VIA Rhine III also have VLAN hardware filtering capabi= lity > > >> > > so it would be even better if we have a way to share common pa= rt. > > >> > > All the patch does is have the vlan driver generate events wh= en it > > >> attaches > > >> > or detaches from a NIC, there are no rules, however I can tell y= ou > > >> > 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 obvious= ly. > > >> > > 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 d= river > > >> > the VLAN tag, this will mean the driver will be able from the st= art > > >> > to use the VFTA, the hardware filter, for each vlan attach the d= river > > >> > will add the ID into this table. > > >> > > The unregister event will turn the table entry off, and if th= is 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > How bout this, we put the change into HEAD, I add support as I've plan= ned > > 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? > >=20 >=20 > 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. >=20 > > Regards, > >=20 > > 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 administra= tor 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 hardw= are is messed up, or neither are messed up, but they are unable to work togethe= r. In these cases the feature could be disabled without hacking the source, wh= ich is a clean solution. FreeBSD has design, and prefers clean solutions as I s= ee. 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 hardw= are 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'. --=20 =C3=9Cdv=C3=B6lettel, Czuczy Gergely Harmless Digital Bt mailto: gergely.czuczy@harmless.hu Tel: +36-30-9702963 --Sig_/il4TY5XZLaETCJstBMO17Lx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFIUM+jzrC0WyuMkpsRAi3iAJ9TXAXn/R3Y+Z5EA1ZvF6A7WhKI3ACginxd Tw0W1Ep5UMUN8sNGFanlAR0= =yfIO -----END PGP SIGNATURE----- --Sig_/il4TY5XZLaETCJstBMO17Lx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080612092621.61b44529>