<<On Sun, 16 Oct 2005 14:06:32 +1000 (EST), Bruce Evans <[EMAIL PROTECTED]> said:
> Probably the problem is largest for latency, especially in benchmarks. > Latency benchmarks probably have to start cold, so they have no chance > of queue lengths > 1, so there must be a context switch per packet and > may be 2. It has frequently been proposed that one of the deficiencies of the sockets model is that too much work must take place in interrupt context. Several alternatives have been suggested, including user-mode protocol processing (e.g., Exokernel) and event-driven receive (can't think of an example here from the literature). In an alternate universe with truly pervasive threading, one might require an application to "donate" a thread to protocol processing -- effectively combining the two approaches I mentioned -- which would be the way to "win" such latency benchmarks. (The application donating the processing power is then also able to donate its memory.) -GAWollman _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
