Subject: RE: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU

From: "Alex Nezhinsky" <[email-masked]>
Date: Wed, 22 Sep 2004 20:12:26 +0200

Mike,

The issue that I tried to address is that the same data is passed to
iSER twice in different descriptors, 
which is potentially unsafe.

I can see two alternatives:
1) Only the solicited data (if any) is passed to Send_Control with the
Command PDU; 
    All unsolicited data is passed piece-wise to Send_Control in
subsequent invocations with Data-OUT PDUs.
2) The entire data (both unsolicited and solicited) is passed to
Send_Control with the Command PDU; 
    subsequent invocations of Send_Control only specify the offset and
length of the data segments 
    in Data-OUT PDUs to send (this is what I suggested previously).

In either way each data portion is described only once.

If it's required that the iSER layer should not save the unsolicited
data descriptors, then the 1) may be acceptable.

On the other hand, one can argue that it is advantageous to save the
entire task data description 
when a command is sent. A possible reason: this memory has to be
registered with a H/W (unsolicited as well) 
so doing it once is more efficient.

Alexander Nezhinsky

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 22 Sep 2004 13:50:33 -0700

Alex,

 > 1) Only the solicited data (if any) is passed to Send_Control with the

We chose not to go this route because in the example of iSER, doing so 
would mean that the zero-based STag's "address 0" would actually be 
UnsolicitedDataSize bytes into the I/O Buffer for the I/O.  This in turn 
  would mean that the target has to subtract this value (assuming that 
target iSER layer keeps a cumulative count of unsolicited # of bytes for 
each command) from the BufferOffset/R2T value to derive the Data Source 
TO for each RDMA Read.  This all seemed like needless complexity.

 >     in Data-OUT PDUs to send (this is what I suggested previously).

This is doable, but the desire to be able to discard the descriptors 
after the memory registration (in the iSER example) is what led to the 
current text.

As you suggested, I would perhaps add an implementation caveat (as in 
11.3.1) to 11.3.5.1 as well.  I hope that addresses the concern.

Thanks.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

---

From: Mike Ko <[email-masked]>
Date: Wed, 22 Sep 2004 14:06:45 -0700

Alex,

Alternative 1 does not work if there are immediate data to be sent with 
the command since the data descriptor in this proposal only specifies 
solicited data.

Alternative 2 requires the datamover to save the information on the data 
buffer when a SCSI Write command is issued and there are unsolicited 
non-immediate data that needs to be sent.  This will require additional 
bookkeeping on the part of the datamover such as creating a local mapping 
that associates the ITT with the data buffer.  There are also additonal 
chores like having to remove the mapping when a SCSI Response is recieved.

So the question is how "potentially unsafe" it is for the iSCSI layer to 
pass DataDescriptorOut to the datamover layer when it invokes the 
Send_Control to send the SCSI Command and SCSI Data-out.  It seems to me 
that this is an implementation issue and it does not justify changing the 
datamover architecture especially since it will create addional 
bookkeeping chores at the datamover. 

Mike
To:     "Mike Ko" <[email-masked]>
cc:     <[email-masked]> 
Subject:        RE: [Ips] DA, Send_Control, DataDescriptorOut parameter of 
Data-OUT PDU

Mike,

Alexander Nezhinsky