> I am a bit concerned here. In the current usage model, target QPs are
> destroyed when their reference
> count goes to zero
> (ib_reg_xrc_recv_qp and ibv_xrc_create_qp increment the reference count,
> while ib_unreg_xrc_recv_qp
> decrements it).
> In this model, the TGT QP user/consumer does n
> Did you have a chance for reviewing those patches?
I did see and flagged them for follow up, but I have not reviewed them yet. I
should get to them sometime this week.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
On Sat, Aug 20, 2011 at 4:47 PM, Bart Van Assche wrote:
> On Mon, Aug 15, 2011 at 6:15 PM, Bob Pearson
> wrote:
> > I want to eventually complete the IB transport parts of the driver although
> > they are not used by RoCE. They would be useful for a soft IB implementation
> > with say an FPGA bas
The rdma_cm uses the local qp_type to determine how to
process an incoming request. This can result in an
incoming REQ being treated as a SIDR REQ and vice versa.
Fix this by switching off the event type instead, and for
good measure verify that the listener supports the incoming
connection reques
Hey Roland,
Is this patch acceptable for heading upstream?
Thanks,
Steve.
On 08/01/2011 04:59 PM, Steve Wise wrote:
The iw_cxgb4 module crashes at init time if the T4 card does not
support RDMA. So clean up the init logic to correctly deal with
non-RDMA cards.
- If any RDMA resources are no
> -#define CMA_CREATE_MSG_CMD_RESP(msg, cmd, resp, type, size) \
> +#define CMA_CREATE_MSG_CMD_RESP(msg, cmd, resp, type, size, clean_cmd) \
This starts to get ugly, especially with usage that ends up looking like this:
> - CMA_CREATE_MSG_CMD_RESP(msg, cmd, resp, UCMA_CMD_DESTROY_ID, size);
>
