From Oracle's perspective I think you can punt on the cluster rolling
upgrade aspect of this.
It's likely that Oracle will be running a newer version of RDS with flow
control - or all nodes will be on an older version.
As long as different versions of drivers interact without crashing the
node - and report a mismatch in protocol - we're probably OK.
Assuming the flow control turns out to not impact performance - then we
should just remove the old RNR code.
If we're ready = I give this version of the driver to our performance
folks - hopefully they can give a bash in the next week or so..
Olaf Kirch wrote:
On Tuesday 20 May 2008 22:45:22 Jon Mason wrote:
Works well on my setup.
Good to hear!
With proper flow control, there should no longer be a need for rnr_retry (as
there
should always be a posted recv buffer waiting for the incoming data). I did a
quick test and removed it and everything seemed to be happy on my rds-stress
run.
I would like to make the setting of the RNR retry/timeout conditional on
whether both ends of the connection support flow control or not - we need
to think of rolling upgrades of a cluster, so mixed environments just have
to work. Unfortunately, the RNR retry count is set prior to establishing
the connection, before we even know whether the remote is capable of doing
flow control.
Is there a way of changing the RNR retry count back to 0 after establishing
the connection?
Olaf
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
