Re: Stackable devices.

[Ben Greear <greearb@candelatech.com>]

Christophe Devriese wrote:
> It would however be considerable effort to do this. Is this going to end up 
> unapplied like my last patch, or ?

I don't get to make this decision..and when I ask such questions...they
are usually ignored unless I also post a working patch....

I think you could start with just supporting bridging without too
much code.

Ben

> 
> Regards,
> 
> Christophe
> 
> On Tuesday 08 August 2006 18:36, you wrote:
> 
>>Christophe Devriese wrote:
>>
>>>On Wed, Aug 02, 2006 at 10:50:08AM -0700, Ben Greear wrote:
>>>
>>>>Currently, the bridge hook logic is something like:
>>>>
>>>>if (bridge-consumed-pkt) {
>>>>	return
>>>>}
>>>>
>>>>// drop through to other layers
>>>>
>>>>
>>>>There are several other hooks I'd like to see added (pktgen receive
>>>>processing,
>>>>mac-vlans, etc).  Each of these hooks are logically similar to the bridge
>>>>hook,
>>>>ie if it consumes the pkt, return, else, drop through to the next hook
>>>>untill
>>>>we get to the regular protocol processing logic.
>>>>
>>>>I would like to be able to chain layer-2 handlers, such as bridge,
>>>>mac-vlan, pktgen such that if one consumed, you break out of the
>>>>handling, else, you try the next handler.  The handlers can be
>>>>dynamically registered and inserted
>>>>in any order, controllable by user-space and/or module load/unload.
>>>>
>>>>For many of the handlers, the logic will re-insert the packet by
>>>>re-calling the
>>>>netif-rx logic, so there would need to be some protection to keep loops
>>>>from occurring that would recurse too much and overflow the stack.
>>>
>>>I'm also a big fan of a generalized system like this. It would need to
>>>catch both the vlan accelerated path and the normal path.
>>
>>Well, it isn't actually needed for VLANs since VLAN's hook is a protocol
>>handler....
>>
>>Ben
> 
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>