> One way to look at VJ's proposal is as a way for every application > on a machine to break modularity and do its own TCP to increase > performance.
to me it looked more like he was calling for more processing to be done in the context of the user process (hence using its current processor), rather than by some central loop (say etherread4()). this doesn't mean it can't be done in kernel mode. (i suppose you'd save a syscall by doing it in a library, but you'd instantly lose all the abstraction that fds give you, as everyone's pointed out.) i imagine that you might get fairly close to his proposal within plan 9 by changing the path between the ``read medium'' loop and the eventual ipread, putting most of the ip processing within ipread() with only some signature checking in the medium reading process, and a non-locking shared memory interface between them (i.e. not a Queue). assuming the processing done in ipiput4 is significant, one could see how this might speed things up, by upping the turnaround time of the etherread loop which is potentially acting as a bottleneck. but that's only from an extremely brief glance at the code - i'm talking from a position of near-total ignorance here, i'm afraid! (BTW, can plan 9 actually use multi-core processors?)
