Jesse Gross wrote: > On Wed, Sep 8, 2010 at 2:42 AM, Sven Eckelmann wrote: > > Hi, > > > > here are some raw references without any judgment. Maybe Marek will send > > some more information about that topic later. > > > > Andi Kleen wrote: > >> Sven Eckelmann writes: > >> > B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a > >> > routing protocol for multi-hop ad-hoc mesh networks. The networks may > >> > be wired or wireless. See http://www.open-mesh.org/ for more > >> > information and user space tools. > >> > >> It seems rather unusual to have the complete routing protocol in > >> kernel. And this is a lot of code. The normal way to do such things is > >> to have the routing policy etc. in a user daemon and only let the kernel > >> provide some services to this. > >> > >> Could you elaborate a bit why this approach was not chosen? > >> > >> I assume if it needs a switch it could have a switching "hot path" layer > >> in kernel and the policy somewhere else. > > Potentially one way to do this is to build on top of Open vSwitch. It > contains a pretty generic flow-based kernel module for forwarding data > packets and making simple modifications. Control packets can be sent > to userspace to handle the routing logic, while data packets remain in > the kernel for performance. This would dramatically reduce the amount > of code that needs to be in the kernel and may even help performance > by simplifying the fast path. > > I don't know the details of your protocol well enough to know if this > is feasible but it seems like something you might want to look into. > Open vSwitch is currently in the process of finalizing its interfaces > to prepare for upstreaming. It sounds interesting. I haven't looked into it yet, but maybe you could easily answer some questions: * Does it allow to generate multiple net_devices on the system? * Does it allow to attach multiple net_devices to a single openvswitch device? * Does the attaching of a net_device to a openvswitch device prevent it to be added to another openvswitch device? * Does it propagate the information about the incoming device to the userspace in case of the not routed packets (everything which should * Does it allow to append extra header information to the packet? * Does it allow fragmentation of packets (not real fragmentation, but more single split)? * Does it allow to define outgoing patterns (on which attached interface goes the thing out again) on packet number or incoming device (the real hardware device it was coming in)? * Is it possible to define rules like: "If this is a broadcast of an udp/ip packet with target port 123 which may or may not have a vlan tag, but is coming directly from the virtual device and is not routed by us, then change the mac address to following"? * Can it be backported to old kernels (~2.6.21 - yes, their are "customers" who need even older kernels due to the fantastic vendors out their)? Thanks, Sven