All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.