Vlan EVENT patch

[Pyun YongHyeon]

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 at 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 at gmail.com>
 > >> 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