MAC-VLANS

In order to get MAC-VLANs to work, the only way I can see to make it happen is to put a hook into dev.c in the:
int netif_receive_skb(struct sk_buff *skb)
method.

The hook looks like this, and immediately follows the bridging code hook in the same method:

#if defined(CONFIG_MACVLAN) || defined(CONFIG_MACVLAN_MODULE)
	if (skb->dev->macvlan_priv != NULL &&
	    macvlan_handle_frame_hook != NULL) {
                if (handle_macvlan(skb) >= 0) {
                        /* consumed by mac-vlan...it would have been
                         * re-sent to this method with a different
                         * device...
                         */
                        return 0;
                }
                else {
                        /* Let it fall through and be processed normally */
                }
	}

#endif

So, the question is: Will this feature be allowed to go in since it needs this hook, regardless of other issues? If it's possible, I'll break out the rest of the patch for inspection...

Thanks,
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Why not do it the same we do normal VLAN's? Ie. directly in the device driver receive method via something akin to the vlan_hwaccel_*() routines.

You mean in eth.c or something? I don't want to have to put identical code in all drivers, if that's what you're suggesting. It could be done to common drivers if the feature is used enough to warrant it, but we definately need a fallback case to work with all generic drivers, just as .1q does.

802.1q works because we have an extra shim header in there..but MAC-vlans have no extra header info. It would be nice to have a separate 'protocol' list that was able to consume the pkt: that would allow this to work w/out additional hacks, and could work for pktgen rx and even bridging. Of course, not all could be active at once, but that is no worse than 'hooks' in that regard. And, evil ppl could re-write the IP stack, of course, but that doesn't bother me as much as some folks :)

Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com