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. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/1a730951-21eb-ae5f-a835-ad92c512978c%40vlnb.net.
