Stackable devices.

[Stephen Hemminger <shemminger@osdl.org>]

On Wed, 2 Aug 2006 11:02:20 +0200
Christophe Devriese <Christophe.Devriese@eurid.eu> wrote:

> On Tuesday 01 August 2006 19:21, you wrote:
> > John W. Linville wrote:
> > >>>I'm just not sure that cleverness is worth the headache, especially
> > >>>since the most clever things usually only work by accident...
> > >>
> > >>Or, work by solid, modular design and small tweaks!
> > >
> > > Point taken.  But stashing little hacks in the networking core for
> > > specific virtual drivers isn't totally modular either.  And even if
> > > it were, "modular design" probably belongs on the list of "things
> > > that can be taken too far", like "everything in userland", "never
> > > use ioctl", and "microkernels are superior". :-)
> >
> > To be honest, I'm not over-joyed to see bridging hooks included
> > in the VLAN code..but if that is what it takes to get bridging
> > and VLANs to play well and be flexible, I think it is a fair price.
> >
> > It certainly wouldn't hurt to have someone take a holistic view of the
> > various L2 device interactions.  Just documenting current functionality
> > on, say, the netdev wiki would be a good first step.
> 
> Ultimate flexibility could be provided by making the netif_rx routine (and the 
> others, including vlan etc), a "virtual" routine.
> 
> That way a list of "filters" could be defined that allow any processing to be 
> done on the packet before it is handed of to the linux kernel's higher 
> layers, including not delivering it on that interface, or delivering it on 
> another interface.
> 
> This would allow very complex implementations including stuff like a 
> high-level l2 bridge, with vlan support, and a number of protocols like rstp, 
> pvst+, ... with relatively simple code, that could be isolated from the main 
> kernel.
> 
> Would anyone be interested in signing off on such a patch ? (which basically 
> creates netif_rx and vlan_acc_netif_rx lists in the net_device structure, and 
> then modify bridging and bonding drivers to just use this) 

I have thought about this, but you end up reinventing System V streams.
The problem is for simple up/down call, the stacking model works fine but
once you add flow-control and multiplexing issues the problem becomes complex.
It is hard to think of a good general solution where the performance wouldn't
end up sucking.

-- 
Stephen Hemminger <shemminger@osdl.org>
"And in the Packet there writ down that doome"