>On Fri, 6 Jul 2001, glen mccready wrote:
>> 60000 conns * 150KB/conn / (3 min * 60 secs/min) = 50MB/s
>> 
>> certainly much different from 50KB/s; you're driving the network pretty
>> hard there.  my bad.  certainly the socket buffers will help, etc, but
>> multiple kthreads won't help you until you're SMP.  the trick is that the
>> IO done by the kthread will have to be non-blocking and it'll have to
>> walk through the buffers passed in; or the callbacks can hold off queuing
>> the work onto the kthread until appropriate secondary conditions are met.
>
>I also screwed up! I went back... It's 15K not 150K. which explains how I
>was managing this over a couple of 100MB cards.
>
>The biggest problem that I encountered with this was with select and poll
>which are just not feasable. Now by going to an efficient AIO 
>implementation I can make it work.

even inefficient aio should help when you manage to avoid building
a poll vector with 60000 fds.

>I would also dearly love to be able to use NetBSD for this rather than
>Linux which I still see as having an aio implementation that sucks.
>Currently this is running on HP-A and L-Class hardware which does seem to
>keep up reasonably well.

the linux aio implementation you mention isn't something standard with
redhat linux so far as i know.  it's also pretty braindead.  what i can
tell you is that i've seen a bucketing poll()ing solution perform as well
as a linux solution that "stalled" socket io in the kernel and only issued
it when an appropriate socket callback was made.  (surprised the hell out
of me.)  so, if you can identify which sockets will "most likely" be ready
each time around and you're willing to run with a timeout on the poll()
you can come up with a pretty efficient solution and avoid the aio
requirement.

anyway, there's more to doing posix aio properly than immediates jumps
to mind and that's what i was pointing out... you also don't need a
thread per process (or per aio event) to put together a "reasonable"
hack job. :-)

glen