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