Re: [PATCHv4] net: Add batman-adv meshing protocol

Jesse Gross wrote:

On Wed, Sep 8, 2010 at 2:42 AM, Sven Eckelmann [off-list ref] 

wrote:

quoted

Hi,

here are some raw references without any judgment. Maybe Marek will send
some more information about that topic later.

Andi Kleen wrote:

quoted

Sven Eckelmann [off-list ref] writes:

quoted

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