On 1/24/20 12:43 AM, Vladislav Bolkhovitin wrote:
>
> On 1/23/20 1:51 PM, The Lee-Man wrote:
>> On Wednesday, January 15, 2020 at 7:16:48 AM UTC-8, Bobby wrote:
>>
>>
>> Hi all,
>>
>> I have a question regarding multi-queue in iSCSI. AFAIK, *scsi-mq*
>> has been functional in kernel since kernel 3.17. Because earlier,
>> the block layer was updated to multi-queue *blk-mq* from
>> single-queue. So the current kernel has full-fledged *multi-queues*.
>>
>> The question is:
>>
>> How an iSCSI initiator uses multi-queue? Does it mean having
>> multiple connections? I would like
>> to see where exactly that is achieved in the code, if someone can
>> please me give me a hint. Thanks in advance :)
>>
>> Regards
>>
>>
>> open-iscsi does not use multi-queue specifically, though all of the
>> block layer is now converted to using multi-queue. If I understand
>> correctly, there is no more single-queue, but there is glue that allows
>> existing single-queue drivers to continue on, mapping their use to
>> multi-queue. (Someone please correct me if I'm wrong.)
>>
>> The only time multi-queue might be useful for open-iscsi to use would be
>> for MCS -- multiple connections per session. But the implementation of
>> multi-queue makes using it for MCS problematic. Because each queue is on
>> a different CPU, open-iscsi would have to coordinate the multiple
>> connections across multiple CPUs, making things like ensuring correct
>> sequence numbers difficult.
>>
>> Hope that helps. I _believe_ there is still an effort to map open-iscsi
>> MCS to multi-queue, but nobody has tried to actually do it yet that I
>> know of. The goal, of course, is better throughput using MCS.
>
> From my old iSCSI target development days, MS is fundamentally not
> friendly to multi-queue, because it requires by the iSCSI spec to
> preserve order of commands inside the session across multiple
> connections. Commands serialization => shared lock or atomic => no
> multi-queue benefits.
>
> Hence, usage of MS for multi-queue would be beneficial only if to drop
> (aka violate) this iSCSI spec requirement.
>
> Just a small reminder. I have not looked in the updated iSCSI spec for a
> while, but don't remember this requirement was anyhow eased there.
>
> In any case, multiple iSCSI sessions per block level "session" would
> always be another alternative that would require virtually zero changes
> in open-iscsi and in-kernel iSCSI driver[1] as opposed to complex
> changes required to start supporting MS in it as well as in many iSCSI
> targets around that currently do not[2]. If I would be working on iSCSI
> MQ, I would consider this as the first and MUCH more preferable option.
>
> Vlad
>
> 1. Most likely, completely zero.
> 2. Where requirement to preserve commands order would similarly kill all
> the MQ performance benefits.
Oops, 'MCS' must be everywhere instead of 'MS'. Something "corrected"
this "for me" behind my back.
Sorry,
Vlad
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/open-iscsi/846665ef-d238-8abd-8d1b-72e494af9dd1%40vlnb.net.
