[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1204241026410.735@wel-95.cs.helsinki.fi>
Date: Tue, 24 Apr 2012 11:01:37 +0300 (EEST)
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To: Eric Dumazet <eric.dumazet@...il.com>
cc: David Miller <davem@...emloft.net>, rick.jones2@...com,
Netdev <netdev@...r.kernel.org>, therbert@...gle.com,
ncardwell@...gle.com, maze@...gle.com,
Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for
TCP
On Tue, 24 Apr 2012, Eric Dumazet wrote:
> On Mon, 2012-04-23 at 22:37 +0200, Eric Dumazet wrote:
>
> > We could try to coalesce ACKs before backlogging them. I'll work on
> > this.
>
> I did an experiment, and found a basic coalescing was not working in
> case of packet loss and SACK storm.
...That case might also have some performance issues at the receiver end
when a hole is filled and TCP pushes stuff higher up.
> Doing a smart coalescing in this case sounds really complex.
Why's that? ...We'd compare options 32-bit at a time (like you already do
anyway) and if we find difference we check the previous bits to validate
it's a SACK option (the changing one should be in the first start-end
pair). ...As long as there's no hole in every other segment we'd be
winners I think.
> Should we really continue this way ?
Why not, but wouldn't it be nicer to coalesce them already in GRO below
with an assumption that GRO is likely to find some "mss" equivivalent
which tells the gap between consecutive ACK (or even SACK) seqnos?
I've been long thinking that it would be nice to run offloading for ACKs
too, and possibly even for SACKs, in both ends, although that might not be
possible with other than GSO/GRO, at least atm.
--
i.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists