On Fri, 2005-04-08 at 12:34, Sean Hefty wrote: > Hal Rosenstock wrote: > > 1. cm_alloc_id does an idr_get_new_above starting at 1. Might this be > > better saving the highest value and starting there so connection IDs are > > less likely to repeat as soon ? > > I _think_ this would result in the IDR tables growing to their maximum > size, which seems worse than repeating the IDs immediately after their > timewait expires. > > > 2. Should ib_create_cm_id check return an error if cm_handler == NULL > > just to make sure ? > > Personally, I don't think it's worth this check for kernel clients, > unless we want to start checking for NULL parameters everywhere.
Incoming REQs currently use this capability anyhow. > While on the CM, I did look at the issue of calling the API out of > order that you had pointed out before (which could result in accessing > a NULL port pointer). I'm not convinced that a simple check for a NULL > port pointer covers all potential problems. For example, I'm not sure > how well the codebase will handle the dynamic removal of a device while > users are attempting to access the device. We may need to handle this at some point. Guess the changes may be larger if/when we get there. A couple more questions: It looks like sending private data in REQ/REP/RTU, but incoming private data isn't handled on the receiving side. Also, in cm_process_send_error(), where the handler is called cm_id_priv->id.cm_handler(&cm_id_priv->id, &cm_event); might that callback request the CM ID destruction ? If so, some code is missing to handle this. Thanks. -- Hal _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general