From: Daniel Seither <post@tiwoc.de>
To: Sven Eckelmann <sven.eckelmann@gmx.de>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)
Date: Sat, 10 Jul 2010 11:59:09 +0200 [thread overview]
Message-ID: <4C38446D.5020603@tiwoc.de> (raw)
In-Reply-To: <201007101040.53995.sven.eckelmann@gmx.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
prev parent reply other threads:[~2010-07-10 9:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 22:28 [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (2) Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 1/8] Staging: batman-adv: Convert names from Java to C style Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 2/8] Staging: batman-adv: Avoid rounding issues for local hna timeout Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 3/8] Staging: batman-adv: Lower resolution for timeouts Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 4/8] Staging: batman-adv: replace manual calculation by msecs_to_jiffies() for better readability Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 5/8] Staging: batman-adv: Add sysfs abi documentation about bonding Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 6/8] Staging: batman-adv: adapting source version to revised versioning scheme Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 7/8] Staging: batman-adv: Add include guards to all header files Sven Eckelmann
2010-06-25 22:28 ` [B.A.T.M.A.N.] [PATCH 8/8] Staging: batman-adv: fix early debugfs deinitialization Sven Eckelmann
2010-06-26 0:36 ` [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3) Sven Eckelmann
2010-06-26 0:36 ` [B.A.T.M.A.N.] [PATCH 1/2] Staging: batman-adv: Allow to build it inside the kernel Sven Eckelmann
2010-06-26 0:36 ` [B.A.T.M.A.N.] [PATCH 2/2] Staging: batman-adv: Remove dependency to PROCFS Sven Eckelmann
2010-07-06 13:04 ` [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3) Sven Eckelmann
2010-07-06 15:20 ` Greg KH
2010-07-06 15:36 ` Sven Eckelmann
2010-07-06 16:17 ` Greg KH
2010-07-09 23:07 ` Sven Eckelmann
2010-07-09 23:40 ` Greg KH
2010-07-10 0:42 ` Daniel Seither
2010-07-10 8:40 ` Sven Eckelmann
2010-07-10 8:54 ` Henning Rogge
2010-07-10 9:09 ` Sven Eckelmann
2010-07-10 9:59 ` Daniel Seither [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C38446D.5020603@tiwoc.de \
--to=post@tiwoc.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=sven.eckelmann@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).