[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