Roland Dreier wrote:
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.
Sounds fine to me. As you've seen, I don't like to type, so MM_EXTENSIONS seems better. :)
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.
I left it out from this first pass because we don't expose any of that in the existing RDMA API. Currently the iwarp providers make up their own keys. EG: ib_reg_phys_mr() should also allow passing in the key, at least according to iWARP verbs. But I don't really see the need...
Steve. _______________________________________________ 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
