Sagi Grimberg wrote on 01/08/2015 05:45 AM: >> RFC 3720 namely requires that iSCSI numbering is >> session-wide. This means maintaining a single counter for all MC/S >> sessions. Such a counter would be a contention point. I'm afraid that >> because of that counter performance on a multi-socket initiator system >> with a scsi-mq implementation based on MC/S could be worse than with the >> approach with multiple iSER targets. Hence my preference for an approach >> based on multiple independent iSER connections instead of MC/S. > > So this comment is spot on the pros/cons of the discussion (we might want to > leave > something for LSF ;)). > MCS would not allow a completely lockless data-path due to command > ordering. On the other hand implementing some kind of multiple sessions > solution feels somewhat like a mis-fit (at least in my view). > > One of my thoughts about how to overcome the contention on commands > sequence numbering was to suggest some kind of negotiable "relaxed > ordering" mode but of course I don't have anything figured out yet.
Linux SCSI/block stack neither uses, nor guarantees any commands order. Applications requiring commands order enforce it by queue draining (i.e. wait until all previous commands finished). Hence, MC/S enforced commands order is an overkill, which additionally coming with some non-zero performance cost. Don't do MC/S, do independent connections. You know the KISS principle. Memory overhead to setup the extra iSCSI sessions should be negligible. 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 post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
