Subject: iSCSI: ImmediateData

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 24 Jul 2001 15:23:16 PDT

[ Attached is an exchange with Julian mid-last week. ]

Julian,

I once again recommend that the default for ImmediateData
be "no".  I would argue that the most simple case should be 
enabled by default - just what we did for InitialR2T - 
not the one that demands more memory for unsolicited 
immediate data.

Comments?
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

- I realized (during plugfest) that ImmdiateData's default is
  "yes".  I recommend making it "no", keeping simple-minded targets
  in view.  This issue is more serious if those simple targets
  do not do a lot of text negotiation, when they will be stuck
  with having to support a DataPDULength worth of immediate data.
  This is also in contrary to the conservative spirit of the default
  for InitialR2T (whose default is "yes").

  Please feel free to take it to ips if you think it's a change that
  warrants comments from a  wider audience.

+++ I did not hear any comment from the plugfest on this.
The rational behind it is that simple software implementions benefit the
most out of it
and the default buffer is small ++

---

From: [email-masked] (Sandeep Joshi)
Date: Wed, 25 Jul 2001 14:19:35 -0400 (EDT)

One could tweak the advertised queue size (max-expCmdSN)
if the target does not have enuf memory.  It would avoid 
the R2T delay on every command.

-Sandeep