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;
Subject: Re: [PATCH V9 3/4] blk-mq: issue directly with bypass 'false' in
 blk_mq_sched_insert_requests
To:     "jianchao.wang" <jianchao.w.wang@oracle.com>
Cc:     ming.lei@redhat.com, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <1543995842-20704-1-git-send-email-jianchao.w.wang@oracle.com>
 <1543995842-20704-4-git-send-email-jianchao.w.wang@oracle.com>
 <6cb12913-3575-d3aa-ff08-f89bcb38b3d6@kernel.dk>
 <b57bbedf-bc7e-7b8d-2217-3e8628ab657c@oracle.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <e25a0ba3-356a-35d9-e22b-63ba124f555a@kernel.dk>
Date:   Wed, 5 Dec 2018 19:13:03 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <b57bbedf-bc7e-7b8d-2217-3e8628ab657c@oracle.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

On 12/5/18 6:11 PM, jianchao.wang wrote:
>> And why aren't we just using the list_empty() check like before, and not
>> having to add the inval cookie value?
> 
> Because we use 'bypass == false' here, so blk_mq_try_issue_directly
> will take over the request totally, so the request will always be
> removed from the list and finally, the list must be empty.
> 
> There is another way to identify the result of blk_mq_try_issue_directly.
> Currently,
> for the 'bypass == true' case,
>     it always return BLK_STS_OK,
> for the 'bypass == false' case,
>     it return the actual result, except for 'force == true' case
>     where the request has to be inserted into hctx dispatch list
>     and return a BLK_STS_OK.
> 
> We could let the 'bypass == true' case also return the actual result to
> show what has been done in the blk_mq_try_issue_directly and thus we could
> get the actual result of the last request.
> 
> Would you mind we handle it like this ?

I like that, sounds better than adding a new qc type.

-- 
Jens Axboe