On Thu, Feb 21, 2013 at 10:27 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Thu, 21 Feb 2013 10:00:07 -0600 > Steve French <smfrench@xxxxxxxxx> wrote: > >> We should do some quick performance runs to verify this - but with >> corking and uncorking the socket explicitly presumably TCP_NODELAY >> should not be needed. >> > > I would think time for that sort of investigation was before you merged > the patch that said we were going to remove it. I assumed that since > you took that patch, you were OK with it. Yes - I am ok with it and it didn't seem to hurt performance. Corking/uncorking explicitly makes more sense if the complex network layers work as expected - but the problem is that they change so best to be safe and at least try some quick tests. > In any case, I'll turn this question around... > > TCP_NODELAY says: Send frames as soon as possible after a sendmsg (or > kernel_sendmsg in this case) > > TCP_CORK says: hold sending until I uncork the socket > > If the socket is CORK'ed then that overrides TCP_NODELAY (at least in > my reading of the code). Since we always cork/uncork the socket now, > what possible benefit could there be to keeping the sockopt=TCP_NODELAY > option around? None if corking/uncorking works as one would intuitively think - but the tcp network layers under us are very complicated. (I am not objecting to the patch to remove sockopt setting - just want to do the simple checks to make sure we don't miss something) -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
