Jesse Gross wrote: > On Wed, Sep 8, 2010 at 2:42 AM, Sven Eckelmann <[email protected]> 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 <[email protected]> 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
signature.asc
Description: This is a digitally signed message part.
