From: Rick Jones <rick.jones2@hp.com>
To: David Laight <David.Laight@ACULAB.COM>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Can I limit the number of active tx per TCP socket?
Date: Thu, 06 Mar 2014 09:17:37 -0800 [thread overview]
Message-ID: <5318ADB1.5050107@hp.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6D3B91@AcuExch.aculab.com>
On 03/06/2014 04:28 AM, David Laight wrote:
> Is it possible to stop a TCP connection having more than one
> tx skb (in the ethernet tx ring) at any one time?
> The idea is to allow time for short sends from the application
> to accumulate so that the transmitted frames are longer.
That is precisely what Nagle is supposed to be doing - at least where
the definition of "time" is the round-trip-time rather than "time it
takes to get transmitted out the NIC."
> Basically I have a TCP connection which carries a lot of separate
> short 'user buffers'. These are not command-response so
> TCP_NODELAY has to be set to avoid long delays.
When you are saturating the receiver and/or the 64K line, are you
certain that not setting TCP_NODELAY means long delays?
From a later message:
> The data is sent out on a 64k line so 1ms is only 8 byte times.
Are you still using a 1460 byte MSS on such a connection?
Perhaps you can set the MSS (or drop the MTU on the 64K line and use
PTMU) to something less to trigger window updates a bit sooner and so
get piggy-backed ACKs rather than delayed ACKs and so not have to set
TCP_NODELAY? Yes, you will have a question of headers versus
headers+data but with TCP_NODELAY set as you have it you are (probably)
already trashing that.
Setting TCP_NODELAY to avoid "long delays" and then having a 64Kbyte/s
link seems a trifle, well, contradictory.
rick jones
next prev parent reply other threads:[~2014-03-06 17:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 12:28 Can I limit the number of active tx per TCP socket? David Laight
2014-03-06 14:15 ` John Heffner
2014-03-06 15:03 ` David Laight
2014-03-06 14:38 ` Eric Dumazet
2014-03-06 14:52 ` Eric Dumazet
2014-03-06 17:17 ` Rick Jones [this message]
2014-03-06 18:09 ` Neal Cardwell
2014-03-06 19:06 ` Rick Jones
2014-03-06 19:09 ` Neal Cardwell
2014-03-06 19:27 ` Eric Dumazet
2014-03-07 10:24 ` David Laight
2014-03-07 12:29 ` David Laight
2014-03-07 14:22 ` Eric Dumazet
2014-03-07 14:35 ` David Laight
2014-03-07 15:00 ` Eric Dumazet
2014-03-07 16:39 ` David Laight
2014-03-07 10:17 ` David Laight
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=5318ADB1.5050107@hp.com \
--to=rick.jones2@hp.com \
--cc=David.Laight@ACULAB.COM \
--cc=netdev@vger.kernel.org \
/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.