From: Daniel Seither <post@tiwoc.de>
To: 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 02:42:45 +0200 [thread overview]
Message-ID: <4C37C205.3030003@tiwoc.de> (raw)
In-Reply-To: <201007100107.57451.sven.eckelmann@gmx.de>
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). 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.
- Daniel
next prev parent reply other threads:[~2010-07-10 0:42 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 [this message]
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
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=4C37C205.3030003@tiwoc.de \
--to=post@tiwoc.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/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