Seagate ST3500630A Serial ATA Native Command Queuing (670K, PDF) - Page 8

How Applications Take Advantage of Queuing, Set Device Bits FIS

Page 8 highlights

Serial ATA Native Command Queuing in the SActive register is cleared, it means that a command with that tag is not outstanding in the drive. The host and drive work together to make sure that the SActive register is accurate at all times. The host can set bits in the SActive register, while the device can clear bits in the SActive register. This ensures that updates to the SActive register require no synchronization between the host and the drive. Before issuing a command, the host sets the bit corresponding to the tag of the command it is about to issue. When the drive successfully completes a command, it will clear the bit corresponding to the tag of the command it just finished. The drive clears bits in the SActive register using the Set Device Bits FIS, shown in Figure 3. The SActive field of the Set Device Bits FIS is used to convey successful status to the host. When a bit is set in the SActive field of the FIS, it means that the command with the corresponding tag has completed successfully. The host controller will clear bits in the SActive register corresponding to bits that are set to one in the SActive field of a received Set Device Bits FIS. 0 Error R Status Hi R Status Lo R I R Reserved (0) FIS Type (A1h) 1 SActive 31:0 Figure 3 Set Device Bits FIS Another key feature is that the Set Device Bits FIS can convey that multiple commands have completed at the same time. This ensures that the host will only receive one interrupt for multiple command completions. For example, if the drive completes the command with tag 3 and the command with tag 7 very close together in time, the drive may elect to send one Set Device Bits FIS that has both bit 3 and bit 7 set to one. This will complete both commands successfully and is guaranteed to generate only one interrupt. Since the drive can return a Set Device Bits FIS without a host handshake, it is possible to receive two Set Device Bits FISes very close together in time. If the second Set Device Bits FIS arrives before host software has serviced the interrupt for the first, then the interrupts are automatically aggregated. This means that the host effectively only services one interrupt rather than two thus reducing overhead. How Applications Take Advantage of Queuing The advantages of queuing are only realized if a queue of requests is built to the drive. One major issue in current desktop workloads is that many applications ask for one piece of data at a time, and often only ask for the next piece of data once the previous piece of data has been received. In this type of scenario, the drive is only receiving one outstanding command at a time. When only one command is outstanding at a time, the drive can perform no re-ordering and all the benefit of queuing is lost. Note that with the advent of Hyper-Threading Technology, it is possible to build a queue even if applications issue one request at a time. Hyper-Threading Technology allows significantly higher amounts of multi-threading to occur such that multiple applications are more likely to have I/O requests pending at the same time. However, the best performance improvement can only be achieved if applications are slightly modified to take advantage of queuing. The modifications to take advantage of queuing are actually fairly minor. Today most applications are written to use synchronous I/O, also called blocking I/O. In synchronous I/O, the function call to read from or write to a file does not return until the actual read or write is complete. In the future, applications should be written to use asynchronous I/O. Asynchronous I/O is nonblocking, meaning that the function call to read from or write to a file will actually return before the request is complete. The application determines whether the I/O has completed by checking for 8

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

Serial ATA Native Command Queuing
in the SActive register is cleared, it means that a command with that tag is not outstanding in the
drive.
The host and drive work together to make sure that the SActive register is accurate at all
times.
The host can set bits in the SActive register, while the device can clear bits in the SActive
register.
This ensures that updates to the SActive register require no synchronization between
the host and the drive.
Before issuing a command, the host sets the bit corresponding to the tag
of the command it is about to issue.
When the drive successfully completes a command, it will
clear the bit corresponding to the tag of the command it just finished.
The drive clears bits in the SActive register using the Set Device Bits FIS, shown in Figure 3.
The
SActive field of the Set Device Bits FIS is used to convey successful status to the host.
When a
bit is set in the SActive field of the FIS, it means that the command with the corresponding tag
has completed successfully.
The host controller will clear bits in the SActive register
corresponding to bits that are set to one in the SActive field of a received Set Device Bits FIS.
Error
R Status Hi
R
Status Lo
R
I
R
Reserved (0)
FIS Type (A1h)
0
SActive 31:0
1
Figure 3
Set Device Bits FIS
Another key feature is that the Set Device Bits FIS can convey that multiple commands have
completed at the same time.
This ensures that the host will only receive one interrupt for multiple
command completions.
For example, if the drive completes the command with tag 3 and the
command with tag 7 very close together in time, the drive may elect to send one Set Device Bits
FIS that has both bit 3 and bit 7 set to one.
This will complete both commands successfully and
is guaranteed to generate only one interrupt.
Since the drive can return a Set Device Bits FIS without a host handshake, it is possible to
receive two Set Device Bits FISes very close together in time.
If the second Set Device Bits FIS
arrives before host software has serviced the interrupt for the first, then the interrupts are
automatically aggregated.
This means that the host effectively only services one interrupt rather
than two thus reducing overhead.
How Applications Take Advantage of Queuing
The advantages of queuing are only realized if a queue of requests is built to the drive.
One
major issue in current desktop workloads is that many applications ask for one piece of data at a
time, and often only ask for the next piece of data once the previous piece of data has been
received.
In this type of scenario, the drive is only receiving one outstanding command at a time.
When only one command is outstanding at a time, the drive can perform no re-ordering and all
the benefit of queuing is lost.
Note that with the advent of Hyper-Threading Technology, it is possible to build a queue even if
applications issue one request at a time.
Hyper-Threading Technology allows significantly higher
amounts of multi-threading to occur such that multiple applications are more likely to have I/O
requests pending at the same time.
However, the best performance improvement can only be
achieved if applications are slightly modified to take advantage of queuing.
The modifications to take advantage of queuing are actually fairly minor.
Today most applications
are written to use synchronous I/O, also called blocking I/O.
In synchronous I/O, the function call
to read from or write to a file does not return until the actual read or write is complete.
In the
future, applications should be written to use asynchronous I/O.
Asynchronous I/O is non-
blocking, meaning that the function call to read from or write to a file will actually return before the
request is complete.
The application determines whether the I/O has completed by checking for
8