bidirectional, long commands + OSD
A message that is not in the archive (sent off-list or not yet received): 1075396141.2381.65.camel@mulgrave
James Bottomley wrote in thread:
bidirectional, long commands + OSD:
Quoted 4 lines · Liran Schour
Quoted 3 lines
A single buffer for both data in and data out will force the user to re-copy the buffer.
We can solve it by using a scatter-gather list. Each buffer will have
its
Quoted 9 lines
Quoted 2 lines
own data
direction flag.This is not necessarily true. Just because it's a single buffer doesn't mean that the read and write areas cannot be separated inside it. The actual implementation in most drivers uses a single data pointer, so if the device starts with DATA IN and transitions to DATA OUT, you should get the output data beginning directly after the input data.
Quoted 5 lines
I know the spec implies that you keep two data pointers (because the device is allowed to do the DATA IN<->DATA OUT transition many times), so possibly we can't get away with something simple as above, but implementing separate data pointers would require modifying every driver.
Most of the HBAs today can't support execution of OSD SCSI commands due to the
extended CDB's length and the bidirectional data movement. But when OSD technology
will catch a momentum we will see more and more vendors that will support this features.
My point is that maybe we can keep the current interface while expanding it to support
the needed features by the SCSI OSD commands.
Quoted 2 lines
which OSD devices have you used? Just ISCSI one's, I assume; what do they do with the data in/out transitions?
I have used only ISCSI and TCP/IP (non SCSI) OSD devices. In the devices that
I have used the transitions of data where isolated - first DATA OUT then DATA IN.
But an OSD device can do the following data transitions: DATA IN (user data) ; DATA OUT
(set attributes data and get attributes list) ; DATA IN (retrieved attributes data).
- Liran
Quoted 9 lines · Liran Schour
Most of the HBAs today can't support execution of OSD SCSI commands due to the
extended CDB's length and the bidirectional data movement. But when OSD technology
will catch a momentum we will see more and more vendors that will support this features.
My point is that maybe we can keep the current interface while expanding it to support
the needed features by the SCSI OSD commands.
Actually, I'm sure they can. Most HBA's operate using a scripted firmware interface (like the LSI scripts or the Adaptec sequencer). As long as the scripts are updated, it's no trouble to support multiple data pointers and large CDBs (even the 53c700, a 1990s era chip can do this). I also know seagate is working on an actual single disc that supports OSD, so I expect even the closed firmware chip sets will eventually be updated.
Quoted 8 lines
I have used only ISCSI and TCP/IP (non SCSI) OSD devices. In the devices that
I have used the transitions of data where isolated - first DATA OUT then DATA IN.
But an OSD device can do the following data transitions: DATA IN (user data) ; DATA OUT
(set attributes data and get attributes list) ; DATA IN (retrieved attributes data).
Yes, that's what I feared. The spec implies this as well. Behaviour like that requires two data pointers.
James