On Thu, 21 Feb 2013 10:31:24 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > 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) > Fair enough, let me know what you find. Thanks, -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
