MAC-VLANS

MAC-VLANS

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: MAC-VLANS

[David S. Miller]

On Tue, 05 Aug 2003 17:33:03 -0700
Ben Greear <greearb@candelatech.com> 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.

Re: MAC-VLANS

[Ben Greear]

David S. Miller wrote:
> On Tue, 05 Aug 2003 17:33:03 -0700
> Ben Greear <greearb@candelatech.com> 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.

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com