On May 4, 2011, at 11:08 AM, Jeff Layton wrote: > On Mon, 2 May 2011 21:40:08 -0400 > andros@xxxxxxxxxx wrote: > >> + if (!test_and_clear_bit(XPRT_WRITE_SPACE, &xprt->state)) >> + return; > > Also, I'm not sure that a single bit really conveys enough information > for this. > > IIUC, sk_write_space gets called when a packet is TCP ACK'ed. It seems > possible that we would sometimes have buffer space available to queue > the packet without sk_write_space being called. With this, we'll > basically be serializing all dynamic slot allocations behind the > sk_write_space callbacks. Which I thought was OK given that the TCP window takes a while to stabilize. > > Consider the case of many small TCP frames being sent after a large one > just got ACK'ed. Only one would be allowed to be sent, even though > there might be enough send buffer space to allow for more. > > Would it instead make more sense to base this on the amount of space > available in the actual socket rather than this bit? So at each write_space, potentially allocate more than one rpc_slot as opposed to allocating one rpc_slot and waiting for the next write_space? I could look at this with the 10G testiing. -->Andy > > -- > Jeff Layton <jlayton@xxxxxxxxxx> -- 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
