Question about bridging code

[Robert Watson]

On Thu, 16 Oct 2003, Fernando A. Paulo wrote:

> this is about the thread regarding the use of a freebsd bridge and
> tap(4) to change the contents of the frames. 
> 
> the solution proposed in the list was to use: 
> 
> net.link.ether.bridge_cfg=fxp0:0,tap0:0,tap1:1,fxp1:1
> 
> then you'd write and application to bridge between clusters 0 and 1. 
> 
> i have a couple of questions, hopefully you can help me: 
> 
> 1) wont the userland bridge kill your application because of all the
> context-switches and copies? 
>  
> 2) are you using any library to rebuild your frames (crc, etc)? i'm
> thinking about libnet. 
>  
> i'd be very glad if you could help me with these doubts. 

I've done something very like this before for some research I did a few
years ago.  We built a user process ethernet bridge using BPF -- the
process opened a BPF descriptor per interface that needed to be bridged,
and then read/write frames using them, rewriting as needed.  We
implemented both link layer and IP-layer filtering.  Because you have to
copy every packet in and out of the kernel, it is fairly expensive --
however, if you just have a single process running on the system most of
the time, there isn't a lot of context switching going on.  The same is
true of natd: natd hurts a lot worse from being in userspace if you
simultaneously run tcpdump or trafshow on the host, since you force
frequent context switches. 

My conclusion from my BPF bridge experience was that prototyping in
userspace made it a lot easier to experiment with changes, and
dramatically reduced the development time.  On the other hand, it did
terrible things to performance on high bandwidth tests, and because we
weren't using mbufs in userspace, made it harder to port to the kernel. 
One nice benefit, though, was that we had TCP/IP people programming TCP/IP
stuff without having to teach them about mbuf semantics or kernel
debugging :-).

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories