Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp899911ybd; Wed, 26 Jun 2019 07:51:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqxjb9QN33K2QJDNgDePrNskaegO5TeczzfjqyBf1psNMFT53rl7l/AmwzSd5WKrh77CZF6D X-Received: by 2002:a63:360d:: with SMTP id d13mr3366288pga.80.1561560679222; Wed, 26 Jun 2019 07:51:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561560679; cv=none; d=google.com; s=arc-20160816; b=p7ZZaC1zUrRVaJd4kDTio0R0lDXSlyDOkyy9+Wo9WjmX4edclLE1jDANytUFajtFJj ePoqnRiXUvF/ZS6epJy7Of5C5kqAnBYWjZwap4Se7qwkPaIAnteYKk7p8BSQ8Ec/sPgD vEL2XLdANjHPmfsyDh6bBsaoluYDy4rxrAmAtvA1BxWvqpwpF+9bRd4VX5a6exRwvgvk nJSxBifc5ITywRTCwH6OJ+imeUv10E/StIh3cnWJETB1fp4tyTBjaGzEc4NDa1Q6pYDT Us7MWtj6/hEtDHN7GfNp+21aFhjDzjyXg6BAfbQuyfEuDdIBbjgZQrFPQaMoCz9Mj0tO VJcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=zKwCVXqNSdxUFQzItp//hcjzWX/6aPHoSCaD5m20WdA=; b=pfGqL7KlDtocOF1r87vkmVd8yjHKtCMM2AzgMP4ZJn6arq50+EN3eDsJwE6Mf6sPTe Nj2PVYWoGcfvYwxGuq9XZ54UMBtIu6TxA3ahUAgi6Z9Mdj/bRhP+yTm7TzQoEw80WaQ7 aw66TjaKLUwaV5q3VbjEq791LxD0hPAxoroBvnMNj17cJkv23lTvKOCmdSxq6RtbMrmO jtZaGK4HY7SkTljKoCQ7g49InQzHx0S8a+fsZpel6dS5nIp+JQbbe5Toi6oO8gz3eVsd JZIwaUbMHzSfU/VDm/1K/7hOkPp0buhLnjwWtP+8R26EM5N2S7rTtESNQy9Oga2LUUDk 1iGA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h96si3574114plb.281.2019.06.26.07.51.03; Wed, 26 Jun 2019 07:51:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728221AbfFZOu5 (ORCPT + 99 others); Wed, 26 Jun 2019 10:50:57 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:41285 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727276AbfFZOu4 (ORCPT ); Wed, 26 Jun 2019 10:50:56 -0400 Received: by mail-wr1-f67.google.com with SMTP id c2so3072816wrm.8 for ; Wed, 26 Jun 2019 07:50:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zKwCVXqNSdxUFQzItp//hcjzWX/6aPHoSCaD5m20WdA=; b=ggkusCuj5YmR9+iz+OqEGPmClbvLdXhu12qEVtxqZMQqCNih8X0Km8TFdEgYAmE8y7 4BHqkBNHOjy8ArQoxU3XsGId6JrhgN9oTw1Y0PVsUYL5JQApbk0HZsGmiELyCowndIQP OX5CdIIZbL3Hc45cmfJortpWS+NlYfS7ZVDF0WwIaTfodKVOQu4xg2rMAVUV/6sOQQFU hVRaUjTvZysb64qQAPvb5VrfG6skhghhm5ySRhqg/QEeKoQO+D3zMpKNEQq4XvBAD0EE p/u/yl7mguRZp/sNt7URYGPd+5s3PQuEBUXnp0Cgli1n5o6Z29JBw4bRViesq2MMxrD0 tBsg== X-Gm-Message-State: APjAAAUssVrF6VcnJkl+MB38n7dqv8TUhk6ENBZtMEsHSVebxBDsRxF6 u0NGZyz6+0pZws9GNSewCODt8A== X-Received: by 2002:a5d:5143:: with SMTP id u3mr3622743wrt.118.1561560653972; Wed, 26 Jun 2019 07:50:53 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:e88d:856c:e081:f67d? ([2001:b07:6468:f312:e88d:856c:e081:f67d]) by smtp.gmail.com with ESMTPSA id x129sm2501891wmg.44.2019.06.26.07.50.53 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 07:50:53 -0700 (PDT) Subject: Re: [PATCH 0/2] scsi: add support for request batching To: dgilbert@interlog.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: jejb@linux.ibm.com, martin.petersen@oracle.com, linux-scsi@vger.kernel.org, stefanha@redhat.com References: <20190530112811.3066-1-pbonzini@redhat.com> <746ad64a-4047-1597-a0d4-f14f3529cc19@redhat.com> <65e5ad25-a475-989a-ce3d-400a8c90cb61@interlog.com> From: Paolo Bonzini Message-ID: Date: Wed, 26 Jun 2019 16:50:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <65e5ad25-a475-989a-ce3d-400a8c90cb61@interlog.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/06/19 16:14, Douglas Gilbert wrote: > > I have no objections, just a few questions. > > To implement this is the scsi_debug driver, a per device queue would > need to be added, correct? Yes, queuecommand would then return before calling schedule_resp (for all requests except the one with SCMD_LAST, see later). schedule_resp would then be called for all requests in a batch. > Then a 'commit_rqs' call would be expected > at some later point and it would drain that queue and submit each > command. Or is the queue draining ongoing in the LLD and 'commit_rqs' > means: don't return until that queue is empty? commit_rqs means the former; it is asynchronous. However, commit_rqs is only called if a request batch fails submission in the middle of the batch, so the request batch must be sent to the HBA. If the whole request batch is sent successfully, then the LLD takes care of sending the batch to the HBA when it sees SCMD_LAST in the request. So, in the scsi_debug case schedule_resp would be called for the whole batch from commit_rqs *and* when queuecommand sees a command with the SCMD_LAST flag set. This is exactly to avoid having two calls to the LLD in the case of no request batching. > So does that mean in the normal (i.e. non request batching) case > there are two calls to the LLD for each submitted command? Or is > 'commit_rqs' optional, a sync-ing type command? It's not syncing. It's mandatory if the queuecommand function observes SCMD_LAST, not needed at all if queuecommand ignores it. So it's not needed at all until your driver adds support for batched submission of requests to the HBA. (All this is documented by the patches in the comments for struct scsi_host_template, if those are not clear please reply to patch 1 with your doubts). Paolo