Docs updated

git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1598 d57e44dd-8a1f-0410-8b47-8ef2f437770f

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.
 
 

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.
 
 

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.

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:
 

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: