Ian McDonald wrote: > On 5/11/07, Vlad Yasevich <[EMAIL PROTECTED]> wrote: >> >> May be for TCP? What about other protocols? >> > >> > There are other protocols?-) True, UDP, and I suppose certain modes of >> > SCTP might be sending streams of small packets, as might TCP with >> > TCP_NODELAY set. >> > >> > Do they often queue-up outside the driver? >> >> Not sure if DCCP might fall into this category as well... >> > Yes DCCP definitely can queue outside the driver. > >> I think the idea of this patch is gather some number of these small >> packets and >> shove them at the driver in one go instead of each small packet at a >> time. >> >> I might be helpful, but reserve judgment till I see more numbers. >> >> -vlad > > As I see this proposed patch it is about reducing the number of "task > switches" between the driver and the protocol. I use task switch in > speech marks as it isn't really as is in the kernel. So in other words > we are hoping that spending more time in each area would keep the > cache hot and work to be done if locks held. This of course requires > that the complexity added doesn't outweigh the gains - otherwise you > could end up in a worse scenario where the driver doesn't send packets > because the protocol is busy linking them. > > As far as I can tell you're not combining packets?? This would > definitely break UDP/DCCP which are datagram based.
If it's combining packets, it would break a lot of other things as well. The proposed usage seems to be to link packets together into a chain and give the whole chain to the driver, instead of handing down one packet at a time. The win might be biggest on a system were a lot of applications send a lot of small packets. Some number will aggregate in the prio queue and then get shoved into a driver in one go. But... this is all conjecture until we see the code. -vlad - 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
