On Wed, Jun 18, 2008 at 07:38:23PM +0200, Markus wrote: > Good evening, > > I'm setting off for writing prototype code for an imaging > application. For this reason, I'm in need of an extremely fast > way to transport large amounts of UDP data to a userland > application. > > A socket implementation does not perform very well, which is the > reason why I'm looking for a better solution to minimize > processing time. My initial idea was to already filter the > traffic with bpf and only hand the datagrams (or parts of them) > I really want out of kernel space. > > To stay somehow portable I realize that using libpcap would be a > saner approach. I would however sacrifice portability over > mediocre performance if it had a serious impact. > > I'd be grateful for some advice towards the filtering, since I > have no idea how well bpf performs with a load in the order of > 800 MBit and more. There's probably a better way to get this done. > Is it realistic to expect no data loss on a machine equipped with > proper hardware? > > As for bpf vs. libpcap: Does anybody have a rough estimate of > the performance advantage of using bpf directly compared to libpcap > on OpenBSD?
bpf is not designed for high speed. It will cause more load in the kernel because the recieved pakets need to be copied in the kernel before passing them on. So better look at your client/server app and try to fix their socket usage (use bpf is not designed for high speed. It will cause more load in the kernel because the recieved pakets need to be copied in the kernel before passing them on. So better look at your client/server app and try to fix their socket usage (use non blocking sockets and poll plus have a look at getsockopt and setsockopt to tune the receive buffer and don't write a ping-pong like protocol). IIRC we where able to blast 2.2Gbps over UDP between two OpenBSD boxes so I think the 800 Mbps should be handable. -- :wq Claudio
