Re: rdma_create_qp() and max_send_wr
Roland Dreier wrote: Getting exactly the right value for max_qp_wr is kind of tricky because of complicated allocation rules. I guess this is just a mlx4 bug in reporting not quite the right value from ibv_query_device(). Maybe the correct way to go for mlx4 is to go min/max that is, report the --minimal-- of max(recv, send) value that would work for an app setting of either of their send or the recv WR numbers. Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rdma_create_qp() and max_send_wr
On Sun, May 22, 2011 at 09:46:21AM +0300, Or Gerlitz wrote: Maybe the correct way to go for mlx4 is to go min/max that is, report the --minimal-- of max(recv, send) value that would work for an app setting of either of their send or the recv WR numbers. I see that OFED already contains a fix for this that Jack pushed. So I guess Jack will send it for upstream submission. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ib_srpt: initial .40-rc1 drivers/infiniband/ulp/srpt merge
On Thu, May 19, 2011 at 8:41 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: This is why in the IB verbs architecture nearly everything is tied to a *device*, not a port. LIO has a feature called access control lists that allows to define which initiators are allowed to log in to a target. For a single-rail HCA it makes most sense to configure that information per HCA. For a dual-rail HCA the most flexible approach is to allow the user to configure ACLs per HCA port. That made me wonder whether it is possible to find out from software whether a dual-port HCA is single-rail or dual-rail. A quick glance at struct ib_device_attr and struct ib_port_attr in rdma/ib_verbs.h didn't yield any field usable for this purpose. Did I overlook something ? Bart. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Return EPROTONOSUPPORT when an RDMA device lacks QP0
On May 20, 2011, at 4:23 PM, Hefty, Sean wrote: mad_agent_priv-agent.mr = ib_get_dma_mr(port_priv-qp_info[qpn].qp- pd, IB_ACCESS_LOCAL_WRITE); in which case it may be safer to check for the NULL pointer. Can you confirm if this was the spot? Yes it was that spot. I did think of that today after I sent the patch. Do you think it would be safer just to check for both pointers QP0 and 1 (depending on the registration)? Yes, it seems safer and easier to maintain if we just validated the pointer. - Sean New patch attached. Ira 0001-Return-EPROTONOSUPPORT-when-an-RDMA-device-lacks-the.patch Description: Binary data
Re: [PATCH v2] Return EPROTONOSUPPORT when an RDMA device lacks QP0
@@ -2738,6 +2745,7 @@ static void init_mad_qp(struct ib_mad_port_private *port_priv, spin_lock_init(qp_info-snoop_lock); qp_info-snoop_table = NULL; qp_info-snoop_table_size = 0; +qp_info-qp = NULL; atomic_set(qp_info-snoop_count, 0); } This bit isn't needed, is it? qp_info is in memory allocated with kzalloc. (We could get rid of the other = 0 / = NULL lines too) - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Return EPROTONOSUPPORT when an RDMA device lacks QP0
On May 22, 2011, at 9:05 PM, Roland Dreier wrote: @@ -2738,6 +2745,7 @@ static void init_mad_qp(struct ib_mad_port_private *port_priv, spin_lock_init(qp_info-snoop_lock); qp_info-snoop_table = NULL; qp_info-snoop_table_size = 0; +qp_info-qp = NULL; atomic_set(qp_info-snoop_count, 0); } This bit isn't needed, is it? qp_info is in memory allocated with kzalloc. (We could get rid of the other = 0 / = NULL lines too) Yes, sorry, revised attached, Ira 0001-Return-EPROTONOSUPPORT-when-an-RDMA-device-lacks-the.patch Description: Binary data
