Messages in this thread | | | From | (Alan Cox) | Subject | Re: http://www.nfr.net/nfr/mail-archive/nfr-users/1999/Feb/0110.html | Date | 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/
| |