From: Jesse Gross <jesse@nicira.com>
To: Sven Eckelmann <sven.eckelmann@gmx.de>
Cc: b.a.t.m.a.n@lists.open-mesh.org, Andi Kleen <andi@firstfloor.org>,
davem@davemloft.net, netdev@vger.kernel.org,
b.a.t.m.a.n@lists.open-mesh.net
Subject: Re: [PATCHv4] net: Add batman-adv meshing protocol
Date: Wed, 8 Sep 2010 11:22:42 -0700 [thread overview]
Message-ID: <AANLkTimnBqkiO26wqEQOm+AgSJgQLtQmAe8R-kB6CqtZ@mail.gmail.com> (raw)
In-Reply-To: <201009081142.31610.sven.eckelmann@gmx.de>
On Wed, Sep 8, 2010 at 2:42 AM, Sven Eckelmann <sven.eckelmann@gmx.de> wrote:
> Hi,
>
> here are some raw references without any judgment. Maybe Marek will send some
> more information about that topic later.
>
> Andi Kleen wrote:
>> Sven Eckelmann <sven.eckelmann@gmx.de> writes:
>> > B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing
>> > protocol for multi-hop ad-hoc mesh networks. The networks may be wired or
>> > wireless. See http://www.open-mesh.org/ for more information and user
>> > space tools.
>>
>> It seems rather unusual to have the complete routing protocol in
>> kernel. And this is a lot of code. The normal way to do such things is
>> to have the routing policy etc. in a user daemon and only let the kernel
>> provide some services to this.
>>
>> Could you elaborate a bit why this approach was not chosen?
>>
>> I assume if it needs a switch it could have a switching "hot path" layer
>> in kernel and the policy somewhere else.
Potentially one way to do this is to build on top of Open vSwitch. It
contains a pretty generic flow-based kernel module for forwarding data
packets and making simple modifications. Control packets can be sent
to userspace to handle the routing logic, while data packets remain in
the kernel for performance. This would dramatically reduce the amount
of code that needs to be in the kernel and may even help performance
by simplifying the fast path.
I don't know the details of your protocol well enough to know if this
is feasible but it seems like something you might want to look into.
Open vSwitch is currently in the process of finalizing its interfaces
to prepare for upstreaming.
WARNING: multiple messages have this Message-ID (diff)
From: Jesse Gross <jesse@nicira.com>
To: Sven Eckelmann <sven.eckelmann@gmx.de>
Cc: netdev@vger.kernel.org, b.a.t.m.a.n@lists.open-mesh.org,
Andi Kleen <andi@firstfloor.org>,
davem@davemloft.net, b.a.t.m.a.n@lists.open-mesh.net
Subject: Re: [B.A.T.M.A.N.] [PATCHv4] net: Add batman-adv meshing protocol
Date: Wed, 8 Sep 2010 11:22:42 -0700 [thread overview]
Message-ID: <AANLkTimnBqkiO26wqEQOm+AgSJgQLtQmAe8R-kB6CqtZ@mail.gmail.com> (raw)
In-Reply-To: <201009081142.31610.sven.eckelmann@gmx.de>
On Wed, Sep 8, 2010 at 2:42 AM, Sven Eckelmann <sven.eckelmann@gmx.de> wrote:
> Hi,
>
> here are some raw references without any judgment. Maybe Marek will send some
> more information about that topic later.
>
> Andi Kleen wrote:
>> Sven Eckelmann <sven.eckelmann@gmx.de> writes:
>> > B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing
>> > protocol for multi-hop ad-hoc mesh networks. The networks may be wired or
>> > wireless. See http://www.open-mesh.org/ for more information and user
>> > space tools.
>>
>> It seems rather unusual to have the complete routing protocol in
>> kernel. And this is a lot of code. The normal way to do such things is
>> to have the routing policy etc. in a user daemon and only let the kernel
>> provide some services to this.
>>
>> Could you elaborate a bit why this approach was not chosen?
>>
>> I assume if it needs a switch it could have a switching "hot path" layer
>> in kernel and the policy somewhere else.
Potentially one way to do this is to build on top of Open vSwitch. It
contains a pretty generic flow-based kernel module for forwarding data
packets and making simple modifications. Control packets can be sent
to userspace to handle the routing logic, while data packets remain in
the kernel for performance. This would dramatically reduce the amount
of code that needs to be in the kernel and may even help performance
by simplifying the fast path.
I don't know the details of your protocol well enough to know if this
is feasible but it seems like something you might want to look into.
Open vSwitch is currently in the process of finalizing its interfaces
to prepare for upstreaming.
next prev parent reply other threads:[~2010-09-08 18:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-05 0:25 [PATCHv4] net: Add batman-adv meshing protocol Sven Eckelmann
2010-09-05 0:25 ` [B.A.T.M.A.N.] " Sven Eckelmann
2010-09-07 17:19 ` Paul E. McKenney
2010-09-07 17:19 ` [B.A.T.M.A.N.] " Paul E. McKenney
2010-09-07 17:56 ` Sven Eckelmann
2010-09-07 17:56 ` [B.A.T.M.A.N.] " Sven Eckelmann
[not found] ` <201009071956.54499.sven.eckelmann-Mmb7MZpHnFY@public.gmane.org>
2010-09-07 18:10 ` Paul E. McKenney
2010-09-07 18:10 ` [B.A.T.M.A.N.] " Paul E. McKenney
[not found] ` <20100907181000.GF2448-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2010-09-07 18:24 ` Sven Eckelmann
2010-09-07 18:24 ` [B.A.T.M.A.N.] " Sven Eckelmann
2010-09-08 7:14 ` Andi Kleen
2010-09-08 7:14 ` [B.A.T.M.A.N.] " Andi Kleen
2010-09-08 9:42 ` Sven Eckelmann
2010-09-08 9:42 ` [B.A.T.M.A.N.] " Sven Eckelmann
2010-09-08 18:22 ` Jesse Gross [this message]
2010-09-08 18:22 ` Jesse Gross
[not found] ` <AANLkTimnBqkiO26wqEQOm+AgSJgQLtQmAe8R-kB6CqtZ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-08 18:58 ` Sven Eckelmann
2010-09-08 18:58 ` [B.A.T.M.A.N.] " Sven Eckelmann
[not found] ` <201009082058.15533.sven.eckelmann-Mmb7MZpHnFY@public.gmane.org>
2010-09-08 19:54 ` Jesse Gross
2010-09-08 19:54 ` [B.A.T.M.A.N.] " Jesse Gross
[not found] ` <AANLkTi=FVyLE6OHTd+_qDbzSLk6fY5j6wBOWkYA810Dj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-08 20:25 ` Sven Eckelmann
2010-09-08 20:25 ` [B.A.T.M.A.N.] " Sven Eckelmann
[not found] ` <201009082225.47498.sven.eckelmann-Mmb7MZpHnFY@public.gmane.org>
2010-09-08 20:42 ` Sven Eckelmann
2010-09-08 20:42 ` [B.A.T.M.A.N.] " Sven Eckelmann
2010-09-08 23:13 ` Justin Pettit
2010-09-08 23:13 ` [B.A.T.M.A.N.] " Justin Pettit
2010-09-08 23:37 ` Jesse Gross
2010-09-08 23:37 ` [B.A.T.M.A.N.] " Jesse Gross
[not found] ` <AANLkTim-jswWzG=H0AQP5Z3byxoR1uXoV-ZhdaZ7+Sqd-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-14 19:21 ` Simon Wunderlich
2010-09-14 19:21 ` [B.A.T.M.A.N.] " Simon Wunderlich
2010-09-08 19:12 ` Marek Lindner
2010-09-08 19:12 ` [B.A.T.M.A.N.] " Marek Lindner
[not found] ` <201009082112.14877.lindner_marek-LWAfsSFWpa4@public.gmane.org>
2010-09-08 20:07 ` Jesse Gross
2010-09-08 20:07 ` [B.A.T.M.A.N.] " Jesse Gross
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=AANLkTimnBqkiO26wqEQOm+AgSJgQLtQmAe8R-kB6CqtZ@mail.gmail.com \
--to=jesse@nicira.com \
--cc=andi@firstfloor.org \
--cc=b.a.t.m.a.n@lists.open-mesh.net \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.