TODO patch (was Re: [openib-general] qp lock in mthca_poll_cq)

[Michael S. Tsirkin]

Hello!
Quoting r. Roland Dreier (roland at topspin.com) "Re: [openib-general] qp lock in mthca_poll_cq":
>     Michael> Wouldnt locking the cq while QP is being destroyed also
>     Michael> work?  And maybe the eq which gets the async events.
> 
> Yes, that's a good idea, trading some locking in the slow destroy path
> for removing an atomic access in the data path.  EQ access is
> currently lock-free, but replacing the atomic_t refcounting of
> individual resources with a per-EQ spinlock should if anything be a
> little more cache friendly.  I'll add this to my TODO list (I need to
> take care that the locking hierarchies are OK to avoid deadlocks).

Here's a TODO patch.


Index: src/linux-kernel/TODO
===================================================================
--- src/linux-kernel/TODO	(revision 795)
+++ src/linux-kernel/TODO	(working copy)
@@ -44,3 +44,12 @@
  - rewrite client_query/sa_client/dm_client so that they are more
    general (better support for component mask, RMPP, etc) and more
    maintainable.
+
+mthca specific tasks:
+ - Reduce the number of locks on poll cq path. Locking the cq while qp
+   is being destroyed might just work (and maybe the eq which gets the
+   async events), trading some locking in the slow destroy path
+   for removing an atomic access in the data path.  eq access is
+   currently lock-free, but replacing the atomic_t refcounting of
+   individual resources with a per-eq spinlock should if anything be a
+   little more cache friendly.