Looking at calls to kernel_sendmsg, and thinking about why I only see a few places that do TCP_NODELAY and TCP_CORK in kernel. Looking at the cifs example. cifs is trying to send packets which vary from about 50-100 bytes for common calls (like lookup) to about 56K for file writes (can be larger if override wsize and max buffer size via insmod parameter), and cifs always uses kernel_sendmsg. For the cifs case, sending individual SMB/CIFS requests to a particular server (socket) are serialized, protected by a mutex, even if many processes are writing to different remote files at one time. Usually one kernel_sendmsg is all that is needed to send an SMB request - does kernel_sendmsg implicitly "cork" the request so that the SMB is not unnecessarily fragmented? If the socket is full, and only a few bytes are sent, multiple sendmsg's may be required to send one smb - should cifs be doing a cork before the loop which calls kernel_sendmsg in smb_sendv in fs/cifs/transport.c and uncork afterward (since the server can't do much processing without getting the whole SMB request except in one narrow case of receivefile on certain write requests)? Especially if we add code to allow setting "TCP_NODELAY" ... to improve GigE performance Are there any cases where we should be setting LOWDELAY instead for this kind of socket? -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
