[openib-general] Re: [PATCH 2/6] [RFC] mthca kernel changes for resizeCQ

Roland Dreier rdreier at cisco.com
Mon Jan 30 14:16:46 PST 2006


    Caitlin> For those devices the best support is provided when the
    Caitlin> consumer allocates the maximum, any logical resizing to a
    Caitlin> smaller size is ignored, and there is *no* extra checking
    Caitlin> (let alone a spinlock) for each cq poll.

There is always a spinlock for a CQ poll with every driver that I've
seen (mthca, ehca, ipath and amso1100).  But as I said I've been
reluctant to put locking in the midlayer, because it penalizes
super-smart hardware that might allow lockless operation.

Allocating the maximum CQ size all the time wastes a _lot_ of memory.
For example, on Mellanox HCAs, the CQ entries are 32 bytes, and CQs
can have up to 64K entries.  So a maximum size CQ takes 2 MB of
memory, which is a big waste when a consumer might only need a 4 KB CQ.

 - R.



More information about the general mailing list