We previously attempted to turn on autotuning of nfsd's tcp receive buffers, enabling better performance on large bandwidth-delay-product networks, but ran into some regressions on local gigabit networks. At the time Trond proposed modifying the server to receive partial rpc calls as they arrive instead of waiting for the entire request to arrive, reasoning that that would a) free up receive buffer space sooner, causing the server to advertise a larger window soon, and b) avoid theoretical deadlocks possible if the receive buffer ever fell below the minimum required to hold a request. That seemed to solve the observed regression, but we didn't completely understand why, so I put off applying the patches. I still don't completely understand the cause of the original regression, but it seems like a reasonable thing to do anyway, and solves an immediate problem, so I've updated Trond's original patch (and split it up slightly)--the main changes required were just to adapt to the 4.1 backchannel reply receive code. I'm considering queueing this up for 2.6.40. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
