Daniel Seither wrote:
> Am 10.07.2010 01:07, Sven Eckelmann wrote:
> > batman-adv works quite well for us - but that doesn't mean that it is
> > good in context of the current kernel development. And who should know
> > it better than the netdev guys.
> 
> Hagen Paul Pfeifer suggested in his message "a generalized architecture
> and a user space implementation of the protocol". What came to my mind
> when I read this again was a division of control plane and
> data/forwarding plane as known from traditional routing.
> 
> The whole forwarding stuff would stay in the kernel, using a simple
> routing table (for destination X, send to node Y on interface Z).

This would go against the bonding/alternating functionality.

> The
> processing of routing messages (OGMs) and creation/update of the routing
> table based on the full originator table could be moved to a user space
> daemon. Relative to packets of regular data transmissions, routing
> messages are not sent and received that often such that processing them
> in user space should not hurt performance (very much), especially when
> compared to the original implementation of batman-adv in the user space.
> 
> Firstly, this approach would improve the architecture by separation of
> concerns, which makes it easier to understand, debug and maintain the
> code. Secondly, it would get easier to play with / improve the routing
> protocol and the metrics if the latter parts were implemented in user
> space. And maybe it is indeed possible to make the kernel part of the
> code agnostic to the used protocol implementation, which would lead to
> the generalized architecture that Hagen envisioned.

Yes, that was what I wanted to discuss with him further. I tried to express my 
view about that topic using

  But it does not work for things which must route ethernet frames as there
  does not exist such a framework and it is hard to create one which everyone
  will like and has enough information to provide all features they need.

Yes, I could imagine that this is an alternative route which could be elegant 
and successful, but the hard part is that we don't have anything that is 
really sufficient to be the general routing framework (see for example the 
unicast fragmentation which is added quite late.. or at least proposed quite 
late). There are even more things coming which are related to some parts of 
the multiple gateway handling (I never saw the implementation of the part I am 
referring to, but as far as I can follow the explanation the routing code must 
be adjusted again when we want to handle the non-dhcp/ndp multiple gateway for 
redundant paths to the non-mesh world situation).

Lets check what we may remove from kernelland when move everything to 
userspace (but don't forget, that the formular would be:
 sizeof(kernelpart) + sizeof(userpart) >> sizeof(current kernelland part)

 * aggregation.* -> complete to userspace (but creates lot of jitter). 
 * bat_debugfs.* -> nearly nothing moves to userspace
 * bat_sysfs.* -> around 60-70% stays inside the kernelland
 * bitarray.* -> stays inside the kernel
 * hard-interface.* -> stays inside the kernel
 * hash.* -> stays inside the kernel
 * icmp_socket.c -> stays inside the kernel
 * main.* -> stays inside the kernel
 * originator.* -> moves to userspace
 * ring_buffer.* -> moves to userspace
 * routing.* -> 80-90% stays inside the kernel
 * send.* -> 60% stays inside the kernel
 * soft-interface.* -> stays inside the kernel
 * translation-table.* -> stays inside the kernel
 * vis.* -> moves to userspace 

This is a quite sketchy list and may misses some important points. 
Nevertheless we see that probably most of the code is just the routing/device 
stuff. So we could really think about splitting batman-adv in two parts: SEMF 
(simple ethernet mesh framework) and batman-adv (the part which does the 
discovery and route management). This doesn't mean that we really move to 
userspace, but that we have a better separation between those two parts inside 
the kernelland.

The first step would be to have more than one soft-interface.

This doesn't mean that this move is good (or bad), but it is a lot smaller 
step which can be discussed much more in detail without forgetting most of the 
important parts while discussing kernelland<->userspace interfaces.

Best regards,
	Sven