Re: [B.A.T.M.A.N.] [PATCHv4] net: Add batman-adv meshing protocol

[Sven Eckelmann <sven.eckelmann@gmx.de>]

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

Jesse Gross wrote:
[...]
> >  * Does it propagate the information about the incoming device to the
> >   userspace in case of the not routed packets (everything which should
> 
> I think the last part of your question got cut off.

Or I simple was distracted and didn't finish the sentence. :)

>  However, packets
> do include metadata about the input device.  Userspace would then be
> able to use the normal Linux mechanisms to find out whatever it needs
> (or look at its own information).
> 
> >  * Does it allow to append extra header information to the packet?
> >  * Does it allow fragmentation of packets (not real fragmentation, but
> > more single split)?
> 
> I'm assuming that both of these questions are for tunneling.  Open
> vSwitch currently supports a few different L2 over L3 tunneling
> mechanisms and has a tunnel library that makes adding additional
> protocols easy.  It probably can't do exactly what you need right now,
> but it should be fairly easy to extend.

Hm, low overhead tunneling is one of the main parts, but if you think that it 
is easy to extend then fine.

> >  * 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)?
> 
> I'm not sure what you mean by "packet number".  It does allow you to
> specify the output interface based on a number of factors, include the
> input device.

It would mean that for example 5 packets goes over device 1, the next 5 
packets goes over 

> > * directly influence the traffic flow, i.e., ARQ for broadcasts,

Could you please comment on that one (taken from Mareks mail). Think about 
that one:
 * A Broadcast packet must be send over wifi (adhoc)
 * This packet is probably dropped due to some interferences. So each node
   must transmit the broadcast more than one time to be (with a good chance
   successful). This is quite essential on l2 based adhoc wifi mesh networks
   (as tests showed - but please ask Marek for the actual test setups)


> There are three basic components that you need running for Open
> vSwitch: the main daemon, ovs-vswitchd, a lightweight configuration
> manager, ovsdb-server, and the kernel module, openvswitch_mod.  You
> would then be able to write a userspace process to communicate with
> the daemons to handle the above.  As I mentioned, the encapsulation
> would likely require some small additions to the kernel module for
> your particular type of tunneling (unless you are flexible and can use
> one of the existing mechanisms).  However, that would be significantly
> less kernel code than this patch.  As a starting point, I would
> recommend playing around with Open vSwitch as a normal switch to get a
> feeling for its operation (see the INSTALL.Linux file in the source
> distribution for instructions).

Without checking any facts: This sounds a little bit heavy - does it only 
sound heavy and in reality is extreme slim? The problem is that it must run on 
those low end, "please don't run code on me, because I cannot crunch numbers 
and have no ram" machines like the FON2100 or WRT54GL.

thanks,
	Sven

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