It almost feels like the channel concept wants a "thread per
connection" model?
No, it means only that your application must be asynchronous -- which
all modern network apps are already.
The INN model of a single process calling epoll(2) for 800 sockets
should continue to work, as should the Apache N-sockets-per-thread
model, as should the thread-per-connection model. All of that continues
to be within the realm of application choice.
I may not have been as clear as I should - I'm not meaning to ask about stuff
like epoll continuing to function etc. If the TCP processing is put in the user
context, that means there is no more parallelism between the application doing
its non-TCP stuff, and the TCP stuff for say the next request, which presently
could be processed on another CPU right? Like when I did the "yes, one can
saturate GbE both ways on a single connection - when netperf runs on a CPU other
than the one doing (some fraction) of the TCP processing" message earlier today
in another thread.
rick jones
on list, no need to cc
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
