A few quick comments (more later): > - New device capability flag added: IB_DEVICE_MEMORY_EXTENSIONS indicates > device support for this feature.
We still have time before 2.6.26 comes out. Rather than moving IB_DEVICE_SEND_W_INV to a new bit number, I think it might be better to just remove IB_DEVICE_SEND_W_INV and make IB_DEVICE_MEMORY_EXTENSIONS (maybe "MM_EXTENSIONS" or "MEMORY_MANAGEMENT_EXTENSIONS" is better?) imply real send-with-invalidate support... so 2.6.26 won't have send-with-invalidate and 2.6.27 will have all of the IB base MM exts (and iWARP equivs) in one capability bit. Any thoughts either way? I'll post a trial balloon patch tomorrow. Second question -- IB BMME and iWARP talk about a key portion (least significant byte) of STag/L_Key/R_Key as being under consumer control. Do we want to expose that as part of this API? Basically it means we need to add a way for the consumer to pass in a new L_Key/STag as part of a lot of calls. - R. _______________________________________________ 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
