lkml.org 
[lkml]   [1999]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: http://www.nfr.net/nfr/mail-archive/nfr-users/1999/Feb/0110.html
Date
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.036 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site