[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <11906297271684-git-send-email-ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 13:28:42 +0300
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To: David Miller <davem@...emloft.net>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
SANGTAE HA <sangtae.ha@...il.com>,
Tom Quetchenbach <virtualphtn@...il.com>,
Baruch Even <baruch@...en.org>
Cc: netdev@...r.kernel.org
Subject: [RFC PATCH net-2.6.24 0/5]: TCP sacktag cache usage recoded
Hi all,
After couple of wrong-wayed before/after()s and one infinite
loopy version, here's the current trial version of a sacktag
cache usage recode....
Two first patches come from tcp-2.6 (rebased and rotated).
This series apply cleanly only on top of the other three patch
series I posted earlier today. The last debug patch provides
some statistics for those interested enough.
Dave, please DO NOT apply! ...Some thoughts could be nice
though :-).
It should improve processing of such likely events as cumulative
ACKs and new forward holed SACK considerably because full walk
is not necessary anymore (old code could have been tweaked to
cover them but it's better to drop each special case handling
altogether and do a generic solution. Redundancy of fastpath
hints and highest_sack stuff is also addressed, however, it
might have slight effect as the hint could point to something
less than highest_sack occassionally, whether that's significant
remains to see... In all cases except hint below highest_sack,
the new solution should perform at least as well as the old code
(with a bit larger constant though, no additional cache misses
though) because the SACK blocks old code choose not to process
should all fall to LINUX_MIB_TCP_FULLSKIP category.
It's possible to improve it easily with RB-tree stuff though
this version is based on code using linked lists. I'm not yet
too sure that I got everything 100% correct as I "tweak"
start/end_seqs and exit skb loops a way that is prone to
off-by-one errors, could miss skb here and there. I'll probably
also recode dsack handling too to avoid recursion.
Stephen, Sangtae, others? experiencing those unexpected RTOs
during recovery of large windowed TCP, could you please give it
a try if it helps any...
--
i.
ps. Our net-2.6.24 (and mainline?) DSACK processing code could
be broken btw. DSACK in the middle of other SACK block during
in-order walk seems to not be processed at all as the earlier
(sorted) block caused skb to advance past it already? (Just
occurred to me, I'll see what I can do to that if I've enough
time).
-
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