[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <564886BC.5020105@dev.mellanox.co.il>
Date: Sun, 15 Nov 2015 15:21:00 +0200
From: Sagi Grimberg <sagig@....mellanox.co.il>
To: Christoph Hellwig <hch@....de>
Cc: linux-rdma@...r.kernel.org, bart.vanassche@...disk.com,
axboe@...com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/9] IB: add a proper completion queue abstraction
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists