RE: hardware VLAN acceleration

RE: hardware VLAN acceleration

[Leech, Christopher]

> Any time VLAN groups exist, the VLAN module should not be unloadable.
> 
> This is a hokey area of how the VLAN layer works and I intend
> to fix it.

OK.  I was just trying really hard to find potential API problems earlier
rather than later, obviously without taking the time to completely
understand the VLAN layer internals :)

I don't see why it wouldn't be desirable to have a method of stopping the
driver from continuing to call vlan_hwaccel_rx, so that the vlan_group could
be freed after all the VIDs were removed.  It could be as simple as
declaring that dev->vlan_rx_register(dev, NULL) is valid.

	Chris

Re: hardware VLAN acceleration

[David S. Miller]

   From: "Leech, Christopher" <christopher.leech@intel.com>
   Date: Thu, 28 Feb 2002 15:38:24 -0800
   
   I don't see why it wouldn't be desirable to have a method of stopping the
   driver from continuing to call vlan_hwaccel_rx, so that the vlan_group could
   be freed after all the VIDs were removed.  It could be as simple as
   declaring that dev->vlan_rx_register(dev, NULL) is valid.

This is how I intended it to be used.  It isn't done now only because
this event does not occur within the VLAN layer :)

Re: hardware VLAN acceleration

[David S. Miller]

   From: "Leech, Christopher" <christopher.leech@intel.com>
   Date: Thu, 28 Feb 2002 15:17:54 -0800

      
   > The group is still valid, groups are never destroyed by the VLAN layer
   > once they are created.
   
   Unless the 802.1q code is built as a module.  It looks to me like if you
   unregistered the virtual interface and unload the 802.1q module, if another
   tagged packet is received tg3 will still call vlan_hwaccel_rx and deref
   tp->vlgrp which now points to who knows what.
   
Any time VLAN groups exist, the VLAN module should not be unloadable.

This is a hokey area of how the VLAN layer works and I intend
to fix it.

RE: hardware VLAN acceleration

[Leech, Christopher]

   
> The group is still valid, groups are never destroyed by the VLAN layer
> once they are created.

Unless the 802.1q code is built as a module.  It looks to me like if you
unregistered the virtual interface and unload the 802.1q module, if another
tagged packet is received tg3 will still call vlan_hwaccel_rx and deref
tp->vlgrp which now points to who knows what.

	Chris

--
Chris Leech <christopher.leech@intel.com>
Network Software Engineer
UNIX/Linux/Netware Development Group
LAN Access Division, Intel

Re: hardware VLAN acceleration

[David S. Miller]

   From: "Leech, Christopher" <christopher.leech@intel.com>
   Date: Thu, 28 Feb 2002 13:47:25 -0800

   Is vlan_rx_kill_vid only there to ensure locking between vlan_hwaccel_rx and
   unregister_802_1Q_vlan_dev?  If so, could this be handled outside of the
   driver?
   
It is there because the VLAN layer has no buisness knowing how to lock
out receive interrupt processing in your driver.

The Acenic driver, for example, uses no SMP locking at all and runs
it's RX interrupts %100 lockless requiring a global "cli()" in order
to implement vlan_rx_kill_vid().

   Also, when a vlan dev is unregistered, does the driver need to know that the
   vlan_group passed in to vlan_rx_register is no longer valid?
   
The group is still valid, groups are never destroyed by the VLAN layer
once they are created.

Franks a lot,
David S. Miller
davem@redhat.com