[rds-devel] IB/iWARP code separation

[Andy Grover]

Let me see if there's anything in here that Rick didn't cover in his
response..

Or Gerlitz wrote:
> As for "the plan" - its seems to me that this plan has a "doing giant
> changes and then stabilizing" state-of-mind. Well, for few years now,
> following the 2.5 failure to see the day light, the linux kernel
> development has taken a different approach of "doing changes small
> enough that can be stabilized in about 14 weeks (semester, kidding...)
> cycles". All the evidences show that the iWARP patch doesn't fall into
> that category.  At a minimum it had to be broken into set of logical
> changes patches that built one on top of the other and can be easily
> reviewed at least by someone that knows the code being changed.

So far there haven't been giant changes to how the code works. It's
moved. TCP went away. Cleanup has been cleaned up. The RDS internals are
unchanged from what's in OFED 1.4 right now, if you're using the IB
transport.

It's not accurate to think that the iwarp rdma patch was done, and all
it needed to be perfect was to be split up and reviewed. There's a fair
amount of more work to do, and giving it its own transport is the best
way to let its development proceed without hindrance.

> The path of taking code (module) of size X to two modules each of size X
> each and then converging to one shared code of size aX and two addons of
> size bX (e.g a=0.9 b=0.1) is possible, but I believe the kernel
> development methods / practices have proved that going the other way
> (taking code of X, finding the aX fraction of general functionality,
> then implementing the bX per-transport functionality) would deliver
> faster and better (larger quality), some people call it start with the
> end-in-mind

Why don't we see where things stand in a month or so.

Regards -- Andy