Sounds ok to me.
Roland Dreier wrote:
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
