All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olof Johansson <olof@austin.ibm.com>
To: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>
Cc: trond.myklebust@fys.uio.no, nfs@lists.sourceforge.net
Subject: Re: [PATCH] SVC sockets don't disable Nagle
Date: Tue, 29 Apr 2003 19:07:21 -0500	[thread overview]
Message-ID: <3EAF13B9.8040402@austin.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304300029360.8473-100000@kenzo.iwr.uni-heidelberg.de>

Bogdan Costescu wrote:
> On Tue, 29 Apr 2003, Olof Johansson wrote:
> 
>>Below patch disables it on the server side as well. For latency reasons, 
>>this should be the desired behaviour NFS at both client and server.
> 
> 
> I disagree with this general statement. Nagle is there in the TCP protocol 
> for a specific reason and enabling or disabling it gives the opportunity 
> to better tune the connection.

Yes, Nagle is there to reduce overhead by aggregating data into segments
and piggybacking them with ACKs. Most significant differences will be
when dealing with a steady but slow pace of characters, say text being
typed over a 9600bps serial line.

> It seems like disabling Nagle is the bolierplate answer for anyone who 
> encounters GigEth or better networking simply because the TCP protocol was 
> not designed for such fast networks. But what happens to others that do 
> not have GigEth ? What is the impact of this change for a slower/congested 
> network ?

There is a chance that small requests and replies (~100 bytes) will not
be aggregated into the same segments but instead sent out separately. In
essence, this will result in some additional network overhead due to
headers, but the response times will be perceived as faster even for 
slower networks.

Since NFS traffic is bursty, it is unlikely that any individual request
or reply will be split up between two segments when it didn't need to.

> If anything, I would like to see this as a per-mount-point and 
> per-export-entry option...

I think it would just clutter the documentation and list of options,
since I don't forsee any practical scenarios in which anyone would have
a positive performance impact from having Nagle enabled.


On a side note: As far as I know, most (all?) other NFS implementations 
out there already disable Nagle.


-Olof

-- 
Olof Johansson                                        Office: 4E002/905
pSeries Linux Development                             IBM Systems Group
Email: olof@austin.ibm.com                          Phone: 512-838-9858




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2003-04-30  0:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-29 22:03 [PATCH] SVC sockets don't disable Nagle Olof Johansson
2003-04-29 22:42 ` Bogdan Costescu
2003-04-30  0:07   ` Olof Johansson [this message]
2003-04-30 12:06     ` Bogdan Costescu
2003-04-30 12:45       ` Trond Myklebust
2003-04-30 14:58       ` Olof Johansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EAF13B9.8040402@austin.ibm.com \
    --to=olof@austin.ibm.com \
    --cc=bogdan.costescu@iwr.uni-heidelberg.de \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.