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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
