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

[Sven Eckelmann <sven.eckelmann-Mmb7MZpHnFY@public.gmane.org>]

[-- Attachment #1: Type: Text/Plain, Size: 3161 bytes --]

Jesse Gross wrote:
> On Wed, Sep 8, 2010 at 2:42 AM, Sven Eckelmann <sven.eckelmann-Mmb7MZpHnFY@public.gmane.org> 
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 <sven.eckelmann-Mmb7MZpHnFY@public.gmane.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]