From 9449c43bc86eec512e71853773f94ae0c6115a8c Mon Sep 17 00:00:00 2001 From: Vladislav Bolkhovitin Date: Thu, 8 Apr 2010 18:28:39 +0000 Subject: [PATCH] Docs updated git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1598 d57e44dd-8a1f-0410-8b47-8ef2f437770f --- iscsi-scst/README | 21 +++++++++++++++++---- iscsi-scst/README_in-tree | 21 +++++++++++++++++---- qla2x00t/qla2x00-target/README | 5 ++++- scst/README | 5 ++++- scst/README_in-tree | 5 ++++- 5 files changed, 46 insertions(+), 11 deletions(-) diff --git a/iscsi-scst/README b/iscsi-scst/README index 3bbcf6b5e..7d71ba5b9 100644 --- a/iscsi-scst/README +++ b/iscsi-scst/README @@ -624,18 +624,31 @@ connected to the target via *separate* sessions, i.e. each VM has own connection to the target, not all VMs connected using a single connection. You can check it using SCST proc or sysfs interface. If you miss it, you can greatly loose performance of parallel access to your -target from different VMs. +target from different VMs. This isn't related to the case if your VMs +are using the same shared storage, like with VMFS, for instance. In this +case all your VM hosts will be connected to the target via separate +sessions, which is enough. 5. Many dual port network adapters are not able to transfer data -simultaneousy on both ports, i.e. they transfer data via both ports on +simultaneously on both ports, i.e. they transfer data via both ports on the same speed as via any single port. Thus, using such adapters in MPIO configuration can't improve performance. To allow MPIO to have double performance you should either use separate network adapters, or find a -dual-port adapter capable to to transfer data simultaneousy on both +dual-port adapter capable to to transfer data simultaneously on both ports. You can check it by running 2 iperf's through both ports in parallel. -6. See SCST core's README for more advices. Especially pay attention to +6. Since network offload works much better in the write direction, than +for reading (simplifying, in the read direction often there's additional +data copy) in many cases with 10GbE in a single initiator-target pair +the initiator's CPU is a bottleneck, so you can see the initiator can +read data on much slower rate, than write. You can check it by watching +*each particular* CPU load to find out if any of them is close to 100% +load, including IRQ processing load. Note, many tools like vmstat give +aggregate load on all CPUs, so with 4 cores 25% corresponds to 100% load +of any single CPU. + +7. See SCST core's README for more advices. Especially pay attention to have io_grouping_type option set correctly. diff --git a/iscsi-scst/README_in-tree b/iscsi-scst/README_in-tree index e780508c2..18abe72ad 100644 --- a/iscsi-scst/README_in-tree +++ b/iscsi-scst/README_in-tree @@ -533,18 +533,31 @@ connected to the target via *separate* sessions, i.e. each VM has own connection to the target, not all VMs connected using a single connection. You can check it using SCST proc or sysfs interface. If you miss it, you can greatly loose performance of parallel access to your -target from different VMs. +target from different VMs. This isn't related to the case if your VMs +are using the same shared storage, like with VMFS, for instance. In this +case all your VM hosts will be connected to the target via separate +sessions, which is enough. 5. Many dual port network adapters are not able to transfer data -simultaneousy on both ports, i.e. they transfer data via both ports on +simultaneously on both ports, i.e. they transfer data via both ports on the same speed as via any single port. Thus, using such adapters in MPIO configuration can't improve performance. To allow MPIO to have double performance you should either use separate network adapters, or find a -dual-port adapter capable to to transfer data simultaneousy on both +dual-port adapter capable to to transfer data simultaneously on both ports. You can check it by running 2 iperf's through both ports in parallel. -6. See SCST core's README for more advices. Especially pay attention to +6. Since network offload works much better in the write direction, than +for reading (simplifying, in the read direction often there's additional +data copy) in many cases with 10GbE in a single initiator-target pair +the initiator's CPU is a bottleneck, so you can see the initiator can +read data on much slower rate, than write. You can check it by watching +*each particular* CPU load to find out if any of them is close to 100% +load, including IRQ processing load. Note, many tools like vmstat give +aggregate load on all CPUs, so with 4 cores 25% corresponds to 100% load +of any single CPU. + +7. See SCST core's README for more advices. Especially pay attention to have io_grouping_type option set correctly. diff --git a/qla2x00t/qla2x00-target/README b/qla2x00t/qla2x00-target/README index 270f2c14b..5740a168b 100644 --- a/qla2x00t/qla2x00-target/README +++ b/qla2x00t/qla2x00-target/README @@ -430,7 +430,10 @@ connected to the target via *separate* sessions. You can check it using SCST proc or sysfs interface. You should use available facilities, like NPIV, to make separate sessions for each VM. If you miss it, you can greatly loose performance of parallel access to your target from -different VMs. +different VMs. This isn't related to the case if your VMs are using the +same shared storage, like with VMFS, for instance. In this case all your +VM hosts will be connected to the target via separate sessions, which is +enough. 2. See SCST core's README for more advices. Especially pay attention to have io_grouping_type option set correctly. diff --git a/scst/README b/scst/README index 059caa384..0e2d500bd 100644 --- a/scst/README +++ b/scst/README @@ -1548,7 +1548,10 @@ connected using a single connection. You can check it using SCST proc or sysfs interface. For other transports you should use available facilities, like NPIV for Fibre Channel, to make separate sessions for each VM. If you miss it, you can greatly loose performance of parallel -access to your target from different VMs. +access to your target from different VMs. This isn't related to the case +if your VMs are using the same shared storage, like with VMFS, for +instance. In this case all your VM hosts will be connected to the target +via separate sessions, which is enough. 6. For other target and initiator software parts: diff --git a/scst/README_in-tree b/scst/README_in-tree index 225fd23d3..3d9b95c21 100644 --- a/scst/README_in-tree +++ b/scst/README_in-tree @@ -1473,7 +1473,10 @@ connected using a single connection. You can check it using SCST proc or sysfs interface. For other transports you should use available facilities, like NPIV for Fibre Channel, to make separate sessions for each VM. If you miss it, you can greatly loose performance of parallel -access to your target from different VMs. +access to your target from different VMs. This isn't related to the case +if your VMs are using the same shared storage, like with VMFS, for +instance. In this case all your VM hosts will be connected to the target +via separate sessions, which is enough. 6. For other target and initiator software parts: