Vlan EVENT patch

[Sam Leffler]

[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.

	Sam