Re: http://www.nfr.net/nfr/mail-archive/nfr-users/1999/Feb/0110.html

Alan Cox (alan@lxorguk.ukuu.org.uk)
Sat, 24 Apr 1999 01:14:37 +0100 (BST)


> But you had a tail-wind. I take it that the bottom half can execute
> more than 100x a second if the machine is otherwise idle. But if
> anything comes along and uses a whole timeslice, the backlog queue
> fills (default size 300) and you start dropping packets on the floor.
> Yes? No?

No. The BH isnt scheduled, it follows the interrupts, tasks cannot hold off
a bh.

> > The fun with NFR isnt the device backlog, its that BSD has a hack built into
> > it basically solely for sniffing tools to use, and Linux doesn't.
>
> That may be the key to getting to *really* high packet rates. But Linux,
> pin their test, slowed down as the packet rate increased. That's what
> made me suspect the backlog. But it's just a guess.

Its partly the packet backlog. This is why I dumped the whole NFR discussion
nobody involved with the entire thing had done any serious investigation into
why and how to solve it.

On the other hand I've had a short conversation with another company doing
similar tools which has been rational and basically ended at "look at
X, Y and Z. If you want to write a BPF driver for linux using the
sock filter hooks then go ahead, let me know if there are any other
problems in the filter structure that might make it hard"

-
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/