On Monday 05 February 2007 19:24, Chris Leech wrote: > It is busy waiting, but only because the TCP socket use initiates the > DMA copies from the softirq and they have time to complete during the > switch back to application context.
But to me it looks as if the code in tcp_recvmsg will also initiate DMA copies when the user calls recvmsg and there is data queued on the socket. So in that case, what you end up doing in the same process context is queue DMA ops -> issue pending -> busy wait. In that case, sleeping would sound like the right approach, wouldn't it? > Going back to sleep and creating > more context switching made things worse. I'm working on seeing if > completion interrupts could be used with a better thought out > implementation, the performance implications aren't fully clear to me > yet. > > For other uses, interrupts are probably desired. The NFS client's RPC code hooks into the data_ready callback, tries to find the task that the reply is going to, and copies the data. So per your argument above, for the NFS client it should be okay to busy wait after switching to the task. This would leave the NFS server, which basically uses some kind of poll/recvmsg scheme. In essence, it doesn't call recvmsg until the data has been queued. I guess this kind of code would benefit from using async IO - then the stack can DMA directly into the buffer and then wake up the process. > It's just not there now, but it can be added easily, it's one bit in > the descriptor and a register read in the interrupt handler to see > which channel(s) need attention. Hm, okay. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - 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
