netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: bcrl@kvack.org
Cc: netdev@vger.kernel.org, rdreier@cisco.com, rick.jones2@hp.com,
	linux-kernel@vger.kernel.org, openib-general@openib.org,
	buytenh@wantstofly.org, arjan@infradead.org
Subject: Re: TSO and IPoIB performance degradation
Date: Mon, 20 Mar 2006 15:00:29 -0800 (PST)	[thread overview]
Message-ID: <20060320.150029.109814021.davem@davemloft.net> (raw)
In-Reply-To: <20060320150941.GD16108@kvack.org>

From: Benjamin LaHaise <bcrl@kvack.org>
Date: Mon, 20 Mar 2006 10:09:42 -0500

> Wouldn't it make sense to strech the ACK when the previous ACK is still in 
> the TX queue of the device?  I know that sort of behaviour was always an 
> issue on modem links where you don't want to send out redundant ACKs.

I thought about doing some similar trick with TSO, wherein we would
not defer a TSO send if all the previous packets sent are out of the
device transmit queue.  The idea was the prevent the pipe from ever
emptying which is the danger of deferring too much for TSO.

This has several problems.  It's hard to implement.  You have to
decide if you want precise state, thereby checking the TX descriptors.
Or you go for imprecise but easier to implement, which is very
imprecise and therefore not very useful state, by just checking the
SKB refcount or similar which means that you find out it's left the TX
queue after the TX purge interrupt which can be a long time after the
event and by then the pipe has empties which is what you were trying
to prevent.

Lastly, you don't want to touch remote cpu state which is what such
a hack is going to end up doing much of the time.

  parent reply	other threads:[~2006-03-20 23:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-06 22:34 TSO and IPoIB performance degradation Michael S. Tsirkin
2006-03-06 22:40 ` David S. Miller
2006-03-06 22:50 ` Stephen Hemminger
2006-03-07  3:13   ` Shirley Ma
2006-03-07 21:44     ` Matt Leininger
2006-03-07 21:49       ` Stephen Hemminger
2006-03-07 21:53         ` Michael S. Tsirkin
2006-03-08  0:11         ` Matt Leininger
2006-03-08  0:18           ` David S. Miller
2006-03-08  1:17             ` Roland Dreier
2006-03-08  1:23               ` David S. Miller
2006-03-08  1:34                 ` Roland Dreier
2006-03-08 12:53                 ` Michael S. Tsirkin
2006-03-08 20:53                   ` David S. Miller
2006-03-09 23:48                   ` David S. Miller
2006-03-10  0:10                     ` Michael S. Tsirkin
2006-03-10  0:38                       ` Michael S. Tsirkin
2006-03-10  7:18                       ` David S. Miller
2006-03-10  0:21                     ` Rick Jones
2006-03-10  7:23                       ` David S. Miller
2006-03-10 17:44                         ` Rick Jones
2006-03-20  9:06                         ` Michael S. Tsirkin
2006-03-20  9:55                           ` David S. Miller
2006-03-20 10:22                             ` Michael S. Tsirkin
2006-03-20 10:37                               ` David S. Miller
2006-03-20 11:27                                 ` Michael S. Tsirkin
2006-03-20 11:47                                   ` Arjan van de Ven
2006-03-20 11:49                                     ` Lennert Buytenhek
2006-03-20 11:53                                       ` Arjan van de Ven
2006-03-20 13:35                                         ` Michael S. Tsirkin
2006-03-20 12:04                                       ` Michael S. Tsirkin
2006-03-20 15:09                                         ` Benjamin LaHaise
2006-03-20 18:58                                           ` Rick Jones
2006-03-20 23:00                                           ` David S. Miller [this message]
2006-04-27  4:13                                 ` Troy Benjegerdes

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=20060320.150029.109814021.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=arjan@infradead.org \
    --cc=bcrl@kvack.org \
    --cc=buytenh@wantstofly.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=openib-general@openib.org \
    --cc=rdreier@cisco.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).