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 [off-list ref]
Candela Technologies Inc http://www.candelatech.com
On Tue, 05 Aug 2003 17:33:03 -0700
Ben Greear [off-list ref] wrote:
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:
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.
David S. Miller wrote:
On Tue, 05 Aug 2003 17:33:03 -0700
Ben Greear [off-list ref] wrote:
quoted
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:
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 [off-list ref]
Candela Technologies Inc http://www.candelatech.com