[rds-devel] [PATCH 03/21] RDS: Congestion-handling code

[Andy Grover]

Or Gerlitz wrote:
> The position you have expressed in the past (e.g in the two posts
> pointed below) is that iWARP and IB would eventually be the same
> transport, such that the separation is temporal. In other posts people
> (I think it was Rick) stated that in the framework RDS is maintained so
> far (hopefully to be changed soon for being under the mainline Linux
> kernel!) you (Oracle) couldn't work on a stable tree (IB only) vs an
> experimental one (IB and iWARP on the same transport), so the approach
> taken was to have one tree with stable/production transport (IB) and
> running-development one (iWARP).

As it turns out, the bugs that Steve Wise has been finding while working
on iWARP have also shown the IB transport in 1.4 to fall over under
stress. The 1.4-future branch that Steve, Jon, and I have been working
on will have separate transports for IB and IW, and will be solid for IB
bcopy and zcopy, and iWARP bcopy. At this point, iWARP can be certified
for RAC.

So what's left. iWARP zcopy. There are a number of differences between
ib and iwarp that need to be handled, and this is where having separate
transports is really handy, because hopefully they can all be hidden
from rds-core and RDS socket users. Once *that* is implemented and
debugged, then Exadata can work on iwarp. And that can be used in
production with no issues other than a little bloat.

Once b and zcopy work on both ib and iwarp, of course we want to get rid
of the code duplication between the two transports. We've been having to
apply common changes twice, and it's really no fun. Whether they can be
merged into a single transport really depends on how extensive the
changes were needed to get iwarp zcopy working were. But it's really an
internal implementation cleanup by this point, no one should see a
difference after the de-duping other than a smaller binary.

> So I wonder if this has been changed. Are you seeing RDS landing in the
> mainline kernel with IB/iWARP being in  separate transports?

Getting RDS in mainline is independent of the development plan above.
There is no reason to hold back from getting in mainline. It will
immediately solve some issues (dynamic PF no longer needed) and it will
bring RDS potentially more users, reviewers, and contributors. While RDS
should mostly work and the code submitted should look nice, we should
not wait until everything is perfect before submitting -- we should
submit early, and then develop against mainline.

Once RDS is in mainline in *any* form, then the process for updates is
straightforward. So I'm not too worried about the specific features in
the version of RDS that gets in initially.

Regards -- Andy