[openib-general][PATCH 1 of 3] repost: Client Reregister support for kernel space

[Sean Hefty]

Eitan Zahavi wrote:
> Well, this is a very old topic well discussed years ago. All credits to
> Ashok Raj which you know better then me. The argument against the idea
> for the SM to be the keeper of these registrations goes as follows:

Yes - and I still don't understand why this isn't a personal problem of the SM.

> Without the use of client re-registration the only way to keep this data
> consistent between the master SM and its standby slaves (or across SM
> restarts) is by using a transaction safe model. 

There are probable other solutions to this problem.  Couldn't the data also be 
written to a shared file system?

> Transaction safe models are well known and require distributed handshake
> or journaling systems (in our case distributed ones). Anyway what this
> means is that every transaction (like creation of new Service Record or
> registering to a multicast group) will have to be first committed and
> approved by all standby SMs before it is responded.
> 
> This strict transaction safe model is not fitting very well with the
> requirement for scalability of the fabric - which is hard to make even
> without that complication. 

How is this less scalable than every client in the fabric maintaining this data, 
detecting failures (if this can be done), and reissuing the requests?

Having standby SMs rely on fabric clients in order to build their database just 
seems like the wrong approach.  If they actually had an up to data database, 
then those SMs could also respond to queries.

- Sean