[Top] [All Lists]

Re: bad TSO performance in 2.6.9-rc2-BK

To: Nivedita Singhvi <niv@xxxxxxxxxx>
Subject: Re: bad TSO performance in 2.6.9-rc2-BK
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Wed, 29 Sep 2004 14:22:52 -0700
Cc: jheffner@xxxxxxx, ak@xxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <415B2647.8080803@xxxxxxxxxx>
References: <20040928223344.GC2975@xxxxxxxxxxxxx> <Pine.NEB.4.33.0409282323220.27103-100000@xxxxxxxxxxxxxx> <20040929140016.7ffa4e8b.davem@xxxxxxxxxxxxx> <415B2647.8080803@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Wed, 29 Sep 2004 14:16:55 -0700
Nivedita Singhvi <niv@xxxxxxxxxx> wrote:

> That was my point to Herbert, Dave - that we can't
> rely on Nagle - either we're triggering too early
> and not utilizing TSO MTU or we're triggering too
> late (waiting for the full TSO frame) depending
> on whether we use standard or TSO mss..
> We need some heuristic to do partial sends under
> TSO. Is that what you are addressing?

It's partial "ACK" of a TSO frame that cause congestion
window and socket buffer allocation issues.

We handle partial sends by just limiting the TSO mss
to never be larger than the congestion window.

We need to handle ACK'ing issues by:

1) Keeping track of "real mss" packet ACKs of TSO
   frames.  This is implemented currently by advancing
   the sequence number of the TSO SKB in the retransmit

2) What I'm working on now, which is to liberate send buffer
   socket space when we do partial acking in #1

I need to see the crash folks are seeing.  Does it only happen
when you have tcpdump attached to the interface running the
test?  Does it happen only on the sender or the receiver
in the netperf test?  Those would be a good clues, indicating
some SKB sharing bug I've created or similar.


<Prev in Thread] Current Thread [Next in Thread>