RE: iscsi : DataPDULength can differ in each direction.

["Rod Harrison" <rod.harrison@windriver.com>]

	Comments below.

	- Rod

  >  -----Original Message-----
  >  From: owner-ips@ece.cmu.edu
  >  [mailto:owner-ips@ece.cmu.edu]On Behalf Of
  >  Dave Sheehy
  >  Sent: Thursday, October 04, 2001 1:33 AM
  >  To: IETF IP SAN Reflector
  >  Subject: RE: iscsi : DataPDULength can differ in each direction.
  >
  >
  >
  >  > 	Can someone give a tangible benefit to this that can
  >  outweigh the
  >  > spec and implementation churn at this late stage of the game?
  >
  >  It would allow iSCSI HBAs to interact more efficiently
  >  with SW iSCSI
  >  implementations and vice versa.
  >

I don't believe it would in practice. Consider the following. The max
PDU size sent during login is more that just that, it is in fact the
senders maximum supportable max PDU size. If one side sends 64k and
the other side 8k although it is technically indicating it can't
receive more than 8k in a single PDU, for all practical purposes it is
also indicating it can't handle, and therefore can't send PDUs bigger
than 8k.

I believe if we go this route we'll simply see the side with the lower
DataPDULength sending its "natural" size PDUs and never sending the
larger size wanted by the other side. More on this below ...

  >  > 	From my point of view the benefit of asymmetric PDU
  >  sizes would have
  >  > to be very large to make it worth the extra complexity
  >  in buffer
  >  > management code alone.
  >
  >  >From the vantage point of an iSCSI HBA it doesn't seem
  >  all that hard.
  >

Well, it seems to me faced with a peer with a different max PDU size
there are relatively few ways to proceed.

If the peer has a lower max PDU size there are 2 choices. Use 2 buffer
pools, one for receive set to the local Max PDU size, and one for send
set to the peer Max PDU size. This is where the extra buffer
management complexity comes in. Or, use one buffer pool and simply
part fill the buffers for sending. This is the easy case.

If the peer has a larger max PDU size then either only send up to the
local PDU size, as I mentioned above, or chain buffers together to
build larger than the local max PDU size. Again, this is where the
extra buffer management complexity comes in. Remember that by
definition these chains will need to be bigger than the largest chain
size the implementation can handle. Unless for some reason the
DataPDULength sent was chosen at some arbitrary size smaller than the
implementations maximum.

None of this is required in the current model where there are 2 simple
choices. Either create buffer pools after login and set them to the
negotiated max PDU size, or use the "natural" local size and part fill
them if it larger than the peer size.

  >  Dave
  >