UDP -> IPoIB -> Verbs
Experts, Is it possible using verbs to send and/or recv UDP data traveling over IPoIB? Or to assocate a socket with a completion queue? -K -- 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
srp_transport: Fix atttribute registration race
Register transport attributes after the attribute array has been set up instead of before. The current code is racy because there is no guarantee that the CPU examining the attribute container will see all values written to the container. Signed-off-by: Bart Van Assche Cc: FUJITA Tomonori Cc: Brian King Cc: David Dillow Cc: Roland Dreier Cc: --- drivers/scsi/scsi_transport_srp.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/scsi_transport_srp.c b/drivers/scsi/scsi_transport_srp.c index 21a045e..07c4394 100644 --- a/drivers/scsi/scsi_transport_srp.c +++ b/drivers/scsi/scsi_transport_srp.c @@ -324,13 +324,14 @@ srp_attach_transport(struct srp_function_template *ft) i->rport_attr_cont.ac.attrs = &i->rport_attrs[0]; i->rport_attr_cont.ac.class = &srp_rport_class.class; i->rport_attr_cont.ac.match = srp_rport_match; - transport_container_register(&i->rport_attr_cont); count = 0; SETUP_RPORT_ATTRIBUTE_RD(port_id); SETUP_RPORT_ATTRIBUTE_RD(roles); i->rport_attrs[count] = NULL; + transport_container_register(&i->rport_attr_cont); + i->f = ft; return &i->t; -- 1.7.3.4 -- 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_CM over RoCE
This is in a lab environment and our network admin was doing some experimentation that he didn't think would affect me since I wasn't using multicast (does rdma_cm use multicast or IGMP?). His description: I was running a test last week to simulate multiple switch hops by connecting the switch to itself (in another vlan) several times. With this setup, I had a host on the lab network that was multiple switch hops away. It appears that one of these other vlans somehow became designated at the IGMP querier and either queries weren’t being sent or weren’t being processed. Removing the first link in this chain caused the queries to start working again. Without an appropriate querier, the switch didn’t think it had to forward any groups (other than the 224.0.0.x reserved range that is always flooded). This kind of odd switch connection would obviously never happen in production. On Thu, Oct 20, 2011 at 4:01 PM, Or Gerlitz wrote: > Kelly Burkhart wrote: > >>> I'm having a problem connecting using RDMA_CM over ethernet >> Actually not. My network admin found some sort of misconfiguration on >> the switch that caused the problem Everything works now. > > Interesting, could you share the nature of problem? > > 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: [PATCH] RDMA/cxgb4: Unblock reads on comp_channel
On Thu, Oct 20, 2011 at 12:30:08 -0500, Steve Wise wrote: > On 10/20/2011 12:25 PM, parav.pan...@emulex.com wrote: > >You are right, cq_lock will result into dead lock. > >Should there be a additional compl_handler spin_lock? > >I was measuring performance impact for adding it, and, irq_save() and > >irq_restore() variant showed additional 200 cycles, which I believe should > >be o.k.? > > > >Parav > > > > Yea, I think adding a comp_handler spin lock would do the trick. I'll let > Kumar come up with this change. I will cook up a patch and post soon. Thanks, Kumar. > > > > >-Original Message- > >From: Steve Wise [mailto:sw...@opengridcomputing.com] > >Sent: Thursday, October 20, 2011 9:52 PM > >To: Roland Dreier > >Cc: Pandit, Parav; kuma...@chelsio.com; linux-rdma@vger.kernel.org; > >d...@chelsio.com > >Subject: Re: [PATCH] RDMA/cxgb4: Unblock reads on comp_channel > > > >On 10/20/2011 11:06 AM, Roland Dreier wrote: > >>On Thu, Oct 20, 2011 at 2:11 AM, wrote: > >>>http://lxr.linux.no/#linux+v3.0.4/Documentation/infiniband/core_locking.txt > >>> > >>>Line no 66 to 97 states that - at a given point of time, there should be > >>>only one callback per CQ should be active. > >>>Is this ensured? > >>> > >>>compl_handler() is invoked from multiple places flush_qp() and > >>>post_qp_event() to my mind. > >>Yes, does look like an issue with this patch :( > >> > >And I think this bug exists in the T3 driver too. > > > -- 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
