Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

Daniel Seither
2010-07-10T09:59:09Z

On 10.07.2010 10:40, Sven Eckelmann wrote:
> Daniel Seither wrote:
>> On 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.

Okay. I didn't really look into this functionality yet, but slightly
extending the routing table by for example multiple next hops should do
the job, right?

> 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.

I agree. Thanks for analyzing the existing code; I'm not that familiar
with the gory details of batman-adv. Your suggestion should yield quite
an improvement from the point of architecture.

- Daniel