> Our question is: Is there an alternative path for "recvfrom" which is > more simple than the current sotpi_recvmsg imeplementation, and will > not lock during copying data from kernel to user space ?
I'm not familiar with the sotpi_recvmsg() codepaths, but a quick look suggests that it would require some reorganization to avoid being under SOREADLOCKED when doing the copyout, since that's done by kstrgetmsg(). Have you compared the performance against having a single thread do the reads on the socket and then farming out the work to worker threads in your application? Hopefully someone with more familiarity in this area will have some other ideas for you to try out. -- meem _______________________________________________ networking-discuss mailing list [email protected]
