netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: Rick Jones <rick.jones2@hp.com>
Cc: netdev@oss.sgi.com
Subject: Re: on the wire behaviour of TSO on/off is supposed to be the same yes?
Date: Fri, 21 Jan 2005 20:49:48 -0800	[thread overview]
Message-ID: <20050121204948.034b2510.davem@davemloft.net> (raw)
In-Reply-To: <41F186A8.9030805@hp.com>

On Fri, 21 Jan 2005 14:48:08 -0800
Rick Jones <rick.jones2@hp.com> wrote:

> Indeed, it seems that one would want to decide about TSO when one is about to 
> transmit, not when the user does a send since otherwise, you penalize users 
> doing larger sends.  Someone doing say a sendfile() of a large file would be 
> pretty much precluded from getting benefit from TSO the way things are now right?

Not really, if the file is larger than the send buffer limit, we'll
have a large enough cwnd once the later packets get built.

The cwnd is sampled when we build packets onto the send queue.
Each socket has a send buffer limit on that, so we only build
until we reach that limit.

At user sendmsg/sendfile time is when we do the segmentation and thus
the packet sizing, because it is the most logical place to do this.

The code can potentially get really messy and ugly if we start
preemptively building larger frames "hoping" the cwnd will be
large enough by the time we push it onto the wire.  Segmenting
at send time is completely upside down to the way packets are
built currently for transmission.  A bad guess also means that
we'll spend significant cycles chopping up TSO packets and
resegmenting the queue.

  parent reply	other threads:[~2005-01-22  4:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-21 19:01 on the wire behaviour of TSO on/off is supposed to be the same yes? Rick Jones
2005-01-21 19:58 ` Jon Mason
2005-01-21 20:18   ` Rick Jones
2005-01-21 20:44     ` David S. Miller
2005-01-21 22:00       ` Rick Jones
2005-01-21 22:18         ` David S. Miller
2005-01-21 22:48           ` Rick Jones
2005-01-21 22:58             ` Rick Jones
2005-01-22  4:44               ` David S. Miller
2005-01-22 18:58                 ` rick jones
2005-01-22  4:49             ` David S. Miller [this message]
2005-01-22 19:05               ` rick jones
2005-01-24 20:33               ` Rick Jones
2005-01-24 20:43                 ` David S. Miller
2005-01-24 21:22                   ` Rick Jones
2005-01-28  0:10                   ` Rick Jones
2005-01-28  0:57                     ` David S. Miller
2005-01-28  1:36                       ` Rick Jones

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=20050121204948.034b2510.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=netdev@oss.sgi.com \
    --cc=rick.jones2@hp.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).