On 09/19/2014 09:35 AM, Bart Van Assche wrote:
> On 09/19/14 17:27, Ming Lei wrote:
>> On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche <bvanassche@xxxxxxx> wrote:
>>> On 09/19/14 16:28, Ming Lei wrote:
>>>>
>>>> On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche <bvanassche@xxxxxxx>
>>>> wrote:
>>>>>
>>>>> @@ -2643,7 +2754,8 @@ static struct scsi_host_template srp_template = {
>>>>> .proc_name = DRV_NAME,
>>>>> .slave_configure = srp_slave_configure,
>>>>> .info = srp_target_info,
>>>>> - .queuecommand = srp_queuecommand,
>>>>> + .queuecommand = srp_sq_queuecommand,
>>>>> + .mq_queuecommand = srp_mq_queuecommand,
>>>>
>>>>
>>>> Another choice is to obtain hctx from request directly, then mq can
>>>> reuse the .queuecommand interface too.
>>>
>>>
>>> Hello Ming,
>>>
>>> Is the hctx information already available in the request data structure ? I
>>> have found a mq_ctx member but no hctx member. Did I perhaps overlook
>>> something ?
>>
>> You are right, but the mq_ctx can be mapped to hctx like below way:
>>
>> ctx = rq->mq_ctx;
>> hctx = q->mq_ops->map_queue(q, ctx->cpu);
>
> Hello Ming,
>
> Had you already noticed that the blk_mq_ctx data structure is a private
> data structure (declared in block/blk-mq.h) and hence not available to
> SCSI LLDs ? However, what might be possible is to cache the hctx pointer
> in the request structure, e.g. like in the (completely untested) patch
> below.
ctx was meant to be private, unfortunately it's leaked a bit into other
parts of block/. But it's still private within that, at least.
Lets not add more stuff to struct request, it's already way too large.
We could add an exported
struct blk_mq_hw_ctx *blk_mq_request_to_hctx(struct request *rq)
{
struct request_queue *q = rq->q;
return q->mq_ops->map_queue(q, rq->mq_ctx->cpu);
}
for this.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
