From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: MLX4 Cq Question Date: Sun, 19 May 2013 09:09:21 +0300 Message-ID: <51986C91.7050308@mellanox.com> References: <51968438.7070907@opengridcomputing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Roland Dreier , Jack Morgenstein Cc: Tom Tucker , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Yishai Hadas List-Id: linux-rdma@vger.kernel.org On 18/05/2013 00:37, Roland Dreier wrote: > you see that when freeing a CQ, we first do the HW2SW_CQ firmware > command; once this command completes, no more events will be generated > for that CQ. Then we do synchronize_irq for the CQ's interrupt > vector. Once that completes, no more completion handlers will be > running for the CQ, so we can safely delete the CQ from the radix tree > (relying on the radix tree's safety of deleting one entry while > possibly looking up other entries, so no lock is needed). We also use > the lock to synchronize against the CQ event function, which as you > noted does take the lock too. > > Basic idea is that we're tricky and careful so we can make the fast > path (completion interrupt handling) lock-free, but then use locks and > whatever else needed in the slow path (CQ async event handling, CQ > destroy). Jack, so do we finally agree to this analysis? last time when this was on the list, I was under the impression that there was no consensus and I also see that on the stack we provide to customers there's a patch of yours in that area, or it may fix another bug? Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html