Given that we should have full support for memory management extensions
pending for 2.6.27, and the support we have for send w/ invalidate in
2.6.26 is incomplete (no provision for returning STag/L_Key in receive
completion and no implementation of that in amso1100 for one thing), I
think it makes sense to simply remove the IB_DEVICE_SEND_W_INV
capability flag rather than moving it to a new bit position.
Then when we add all the memory management extension support in 2.6.27,
we can just use bit 21 for IB_DEVICE_MEM_MGT_EXTENSIONS and avoid having
such fine grained distinctions, and avoid having all sorts of strange
code to monkey around with the SEND_W_INV bit in libibverbs and
userspace driver libraries.
Thoughts pro or con?
- R.
diff --git a/drivers/infiniband/hw/amso1100/c2_rnic.c
b/drivers/infiniband/hw/amso1100/c2_rnic.c
index 9a054c6..b1441ae 100644
--- a/drivers/infiniband/hw/amso1100/c2_rnic.c
+++ b/drivers/infiniband/hw/amso1100/c2_rnic.c
@@ -455,8 +455,7 @@ int __devinit c2_rnic_init(struct c2_dev *c2dev)
IB_DEVICE_CURR_QP_STATE_MOD |
IB_DEVICE_SYS_IMAGE_GUID |
IB_DEVICE_ZERO_STAG |
- IB_DEVICE_MEM_WINDOW |
- IB_DEVICE_SEND_W_INV);
+ IB_DEVICE_MEM_WINDOW);
/* Allocate the qptr_array */
c2dev->qptr_array = vmalloc(C2_MAX_CQS * sizeof(void *));
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 911a661..31d30b1 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -105,7 +105,6 @@ enum ib_device_cap_flags {
*/
IB_DEVICE_UD_IP_CSUM = (1<<18),
IB_DEVICE_UD_TSO = (1<<19),
- IB_DEVICE_SEND_W_INV = (1<<21),
};
enum ib_atomic_cap {
_______________________________________________
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
