On Mon, Apr 28, 2008 at 01:57:54PM -0700, Stephen Hemminger wrote: > I looked at this, and thought about cleaning it up and putting in > next release but right now can't see how it could work with > vlan accelerated hardware. ¿Did you see my last mail? I made the cleaning up you suggested and generalized the code to support any level of nested tags instead of just two. > Your patch doesn't work if hardware does vlan acceleration. Vlan acceleration > strips the tag off so skb->data points to actual contents and tag is passed > up to vlan_receive_skb out of band. By the time the bridge sees the packet the > actual tag is gone. Yes, I know. However, AFAIK out of band passing of the vlan tag is only done when a vlan device is created and attached to the ethernet device of the port. That's a weird case from my point of view: brctl addif br0 eth0 vconfig add eth0 5 If you want to get vlan packets from a bridge, you'd better attach the device to the bridge instead of one of the ports: brctl addif br0 eth0 vconfig add br0 5 If you attach it to a port, the out of band tag won't reach current bridge code, and won't be restored on bridge output in case the packet has to be forwarded. Attaching the vlan device to the bridge device doesn't enable hardware vlan acceleration, so that everything works. > You might be able to get tag by using some API to reference the VLAN device, > but it all gets complex and racy. Plus not sure if it is really even technically > correct. I guess the complexity overwhelms the benefits. Anyway, if that case is to be handled I think that restoring the tag on output is more important. _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge