netdev - Re: Reviewing batman-adv for net/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201006281055.47004.sven.eckelmann@gmx.de>
Date:	Mon, 28 Jun 2010 10:55:45 +0200
From:	Sven Eckelmann <sven.eckelmann@....de>
To:	b.a.t.m.a.n@...ts.open-mesh.org
Cc:	Hagen Paul Pfeifer <hagen@...u.net>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	b.a.t.m.a.n@...ts.open-mesh.net
Subject: Re: Reviewing batman-adv for net/

Hagen Paul Pfeifer wrote:

Thanks for your comments. Marek already answered the first two questions, and 
I will write something about the last part.

[...]
> o The major code is twisted about bookkeeping stuff, configuration aspects
> and so on. The minor codebase is about protocol processing. What about a
> generalized architecture and a userspace implementation of the protocol?
> And communication via netlink sockets.

Even if it sounds interesting to have a userspace implementation - it just 
doesn't work. Maybe you have something different in mind - so please comment a 
little bit more about about your idea.

There were different implementations for that protocol, first one was a 
complete userspace implementation - but it was just slow and not really 
usable. The second one was not using skb because it was only a port of the 
userspace implementation to the kernel. It was faster (better throughput, not 
as much latency added), but still we noticed that we couldn't saturate our 
fast links due to the overhead we added. That was the time the current form of 
processing and forwarding using skbs was implemented. It was quite plain to us 
that those "tiny" parts must be processed as fast as possible and we are not 
able to communicate a lot inside the kernel to get the information we need to 
forward packets or process new ones.

So I would assume that when we communicate with userspace which does some 
processing of the incoming packets and changes them to get forwarded, we would 
have the same overhead problems as before. That means we add unnecessary 
latency and reduce the throughput a lot.

It works quite well for layer 3 mesh protocols (olsr, batman, babel, bmx, ..) 
because they must not care about the actual routing of the packets - 
everything is done by the IP routing code. But it does not work for things 
which must route ethernet frames as there does not exist such a framework and 
it is hard to create one which everyone will like and has enough information 
to provide all features they need. Meshing with ethernet frames is relative 
young (please correct me) and we see all the time that we need more things 
which couldn't be done by layer 3 (or at least with a lot more work). An 
example would be interface interface alternating which can reduce 
interferences when communicating over many hops.

thanks,
	Sven

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)