Date: Thu, 16 Oct 2003 17:18:24 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: "Fernando A. Paulo" <feapaulo@yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: Question about bridging code Message-ID: <Pine.NEB.3.96L.1031016171427.64529F-100000@fledge.watson.org> In-Reply-To: <20031016200604.72938.qmail@web41501.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031016171427.64529F-100000>