Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> I'm not sure I got it right but it looks OK to me.
>
> I don't really see any other way to do this, because the RESIZE_CQ
> command can block, so we can't lock out poll CQ operations while the
> firmware command is executing.
I thought about this some more. Its unfortunate that there's an overhead
on each poll cq operation.
We could avoid this overhead by:
- adding poll_cq callback and lock into the struct ib_cq,
initializing them on cq creation.
- modifying ib_poll_cq to
static inline int ib_poll_cq(struct ib_cq *cq, int num_entries,
struct ib_wc *wc)
{
unsigned long flags;
int ret;
spin_lock_irqsave(cq->lock, flags);
ret = cq->poll_cq(cq, num_entries, wc);
spin_unlock_irqrestore(cq->lock, flags);
return ret;
}
Now, device driver can modify the poll_cq callback in the cq
to a slower version that checks two buffers for the duration of the resize
operation.
How does this sound?
--
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
