Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751850AbbKONVI (ORCPT ); Sun, 15 Nov 2015 08:21:08 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:34868 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418AbbKONVF (ORCPT ); Sun, 15 Nov 2015 08:21:05 -0500 Subject: Re: [PATCH 2/9] IB: add a proper completion queue abstraction To: Christoph Hellwig References: <1447422410-20891-1-git-send-email-hch@lst.de> <1447422410-20891-3-git-send-email-hch@lst.de> <564852F2.5080602@dev.mellanox.co.il> <20151115125501.GB2218@lst.de> Cc: linux-rdma@vger.kernel.org, bart.vanassche@sandisk.com, axboe@fb.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org From: Sagi Grimberg Message-ID: <564886BC.5020105@dev.mellanox.co.il> Date: Sun, 15 Nov 2015 15:21:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151115125501.GB2218@lst.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1492 Lines: 36 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/