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

[Daniel Seither <post@tiwoc.de>]

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