Tom Tucker wrote: > Not to jump in late on this, but why couldn't we just add a > protocol parameter to the create_id call. Then it is > arbitrarily extensible ala socket(AF_INET, SOCK_STREAM, <protocol!!!>) > > > So what I'm specifically suggesting is: > > struct rdma_cm_id* rdma_create_id(rdma_cm_event_handler* cm_handler, > void* context, rdma_cm_proto proto); > > > Then we don't need a new call, it's extensible to new > protocols, and it's not a single purpose is_sdp parameter. > That's an excellent suggestion, if we think that this is an area that will be extensible. So far in iWARP we have RDMAC MPA, SDP, IETF MPA using unstructured private data and IETF MPA using the IT-API structure private data. And IB we have unstructured private data and TCP compatible connection setup private data.
If we're confident that there is a dominant one for each transport, and the others are merely transitional relics, then the extra methods make the most sense. If we don't think things are really settled then the 'proto' argument makes a lot of sense. The crux question remains though, will there ever be a caller that does not specify the 'proto' as a constant? If there's a scenario for that, then having a parameter in the call rather than a case statement in the caller makes a lot of sense. But if every actual use will select a constant value then what is gained by having a single method? _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
