[RFC] stuff from tcp-2.6 partially merged to upcoming net-2.6.24?

[RFC] stuff from tcp-2.6 partially merged to upcoming net-2.6.24?

[Ilpo Järvinen]

Hi Dave,

...Noticed you were planning to open net-2.6.24 tree... IMHO, part of the 
stuff in tcp-2.6 could be merged to 2.6.24. I suggest that most of the 
stuff which is not directly related to the rbtree, new lost marker, nor
sacktag reorganization are taken. Some of those things are very trivial
to take as they do not introduce have any conflicts. Besides that there 
are some stuff that would need some work if takes as they are built on 
top of stuff that will remain only in tcp-2.6 (includes left_out removal 
and IsReno/Fack conversion)... But if it's ok, I could try to come up with 
a solution even to them... Perhaps do this in two (or more) stages by 
first taking the trivial ones...

I tried rebasing tcp-2.6 (there's some not yet submitted work on top of 
it too) to top of be1b685fe6c9928848b26b568eaa86ba8ce0046c, result is 
here:
  http://www.cs.helsinki.fi/u/ijjarvin/tcp-rebase/{before,after}
...There was at least one gotcha (sacktag's flag reset position change
when sacktag_state is created). But all in all, conflicts weren't that 
hard to resolve... One may resolve some things differently than I did,
so YMMV if you want to try that yourself... :-) ...I also diffed
all.patch'es to see if there was some undesired side-effect from diff 
but didn't find any. Currently only compile tested.

Do you have any suggestion how I should proceed? Or do you perhaps object 
such partial merge completely? ...I could try to come up with a cleaned up 
patch series which has original and their bug fix parts combined to a 
single patch per change (would provide cleaner history and shouldn't be 
very hard to do either)...

-- 
 i.

Re: [RFC] stuff from tcp-2.6 partially merged to upcoming net-2.6.24?

[David Miller]

From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 7 Aug 2007 16:19:58 +0300 (EEST)

> Do you have any suggestion how I should proceed? Or do you perhaps object 
> such partial merge completely? ...I could try to come up with a cleaned up 
> patch series which has original and their bug fix parts combined to a 
> single patch per change (would provide cleaner history and shouldn't be 
> very hard to do either)...

Thank you for doing the rebase.  I agree with you that we should
seperate out as much of the non-rb-tree stuff as possible and put it
into net-2.6.24

I'll will try hard to make time to look at your rebase and try to move
things forward.  I've been all-consumed by the NAPI work and a driver
I've been writing in the background for the past few weeks.

Re: [RFC] stuff from tcp-2.6 partially merged to upcoming net-2.6.24?

[Ilpo Järvinen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2501 bytes --]

On Wed, 8 Aug 2007, David Miller wrote:

> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Tue, 7 Aug 2007 16:19:58 +0300 (EEST)
> 
> > Do you have any suggestion how I should proceed? Or do you perhaps object 
> > such partial merge completely? ...I could try to come up with a cleaned up 
> > patch series which has original and their bug fix parts combined to a 
> > single patch per change (would provide cleaner history and shouldn't be 
> > very hard to do either)...
> 
> Thank you for doing the rebase.  I agree with you that we should
> seperate out as much of the non-rb-tree stuff as possible and put it
> into net-2.6.24

...It would also help a lot in case we at some point of time in the future 
decide to merge rb-tree stuff but then have to back up to have it merged 
in a cleaner state which is easier to revert than with cleanups 
combined... Besides once I get some additional bits done (haven't yet 
dared to do L-bit cascade surgery which will fix timedout loop entry 
bugs and allow dropping of retrans hint counter), long enough mm sit would 
be nice route to rbtree stuff since there it's getting at least bit more
versitile testing that we alone can put to it...

> I'll will try hard to make time to look at your rebase and try to move
> things forward. 

...I case you want to validate them, git-patch-id helps to exclude 
identical changes between before and after allowing you to spend more
time on things that required non-trivial resolution...

> I've been all-consumed by the NAPI work and a driver I've been writing 
> in the background for the past few weeks.

...I can try to help... I suggest that as first step we take all changes 
that do not cause any conflicts (I've already tried cherry-picks), only 
thing I'm not sure whether I should combine change+fix parts or keep 
them as they were in tcp-2.6 (I suggest we combine them but you may 
disagree..?). I can either post them as series or give you them in 
--pretty=oneline format if you want to cherry-pick them yourself (in 
that case having a common tree would help a bit as commit ids would
match as well then)).

However, at least highest_sack inclusion (no space loss as one hint 
counter can be then dropped and allows accurate fackets out which I've 
partially coded already) will need also SACK-block validator. But I
basically have to redo as the validator patch was sacktag reorganization 
based previously (I've already found couple of improvements too to it's
accuracy :-))...


-- 
 i.