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,<parav.pan...@emulex.com> 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
