On 15/11/2015 14:55, Christoph Hellwig wrote:
On Sun, Nov 15, 2015 at 11:40:02AM +0200, Sagi Grimberg wrote:
I doubt INT_MAX is useful as a budget in any use-case. it can easily
hog the CPU. If the consumer is given access to poll a CQ, it must be
able to provide some way to budget it. Why not expose a budget argument
to the consumer?
Because in theory we could have a lot of sends completing before
we finally need to reap them. I think that's more of a theoretical
than real issue.
Still, processing a CQ possibly forever is not something we'd want to
enable in an API, if a caller wants to do that anyway, it should loop
this call...
My preference would be to simply kill this mode though. Allocate a IU
to each block request in SRP and only use the free_tx list for task
management and AEN/req_limit calls. Then we can use a single CQ
and mark the regular I/O requests as unsignalled.
It might be better. I'd say that we keep this API and let Bart decide
if he wants to do that in srp. If he wants to convert srp, we can
always drop it.
AFAICS no other driver wants a similar polling mode as the SRP initiator
does for it's send queue.
iser worked in this mode in the past. But we changed that.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
