I was under the impression that they used some hack to mmap a kernel
ring buffer via a character device. Someone is implementing that on Linux
too, although I tried to talk them out of it (and put their time into a better
libpcap instead). Their code will run in the IRQ at the end and probably
be rather similar to turbopacket.
>
> > This could be fixed by a libpcap that uses a few worker threads
> > for packet recvmsg'ing.
>
> I do not remember a case, when threads helped to get CPU ticks magically.
> It really helps to reduce latency a bit by using blocking io instead of
> poll/read, but it is inessential when doing bulk work. NFR spends
> lots of time analyzing packets, copies lots of useless data,
> system overhead is negligible.
And lots of time writing data to disk + a complex multi process setup.
Some gaps inbetween where there are wasted cycles in waiting wouldn't
be that surprising. The multithread model also has the advantage that
it keeps the kernel packet queues short (ok, I could increase the rcvbuf
to a very huge value, but I would prefer to do that in a user space ring
buffer)
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/