Re: iscsi : DataPDULength can differ in each direction.

[Dave Sheehy <dbs@acropora.rose.agilent.com>]

Julian,

> Implementation specific? I assume you wanted to say connection specific.

No, I said what I meant and I meant what I said. :-)

I can easily envision implementation restrictions (bounds if you will) with
regard to any of the parameters I listed. I think you are being far too
optimistic that implementors will enable all that the spec allows.

In particular:

> Following this same line of reasoning the keys:
> 
>            MaxBurstSize
>            FirstBurstSize

An implementation can easily be limited by the size of burst it can handle
due to buffering capacity or other data structure limitations of the HW.

>            MaxOutstandingR2T

This requires resources in the HW implementation to track the outstanding 
requests. Implementations will vary in the capacity of tracking said requests.

>            DataPDUInOrder
>            DataSequenceInOrder

Some HW implementations will limited in their capability to handle out of 
order data. Current Fibre Channel implementations illustrate this type of 
constraint well.

>            ErrorRecoveryLevel

Implementations may limit the types of error recovery available. I can
envision different implementation choices being made in the ability to 
restart IOs. I also think it may be problematic moving and restarting an
IO between implementations.

> No the parameters you quote (except MaxOutstandingR2T) are not connection
> specific.
> They reflect multiplexing capability that the transport allows for SCSI.
> Making them connection specific will
> only complicate things with no added benefit.

In which case you add the complication that the iSCSI layer will have to
query (or know apriori) the capabilities of all its interfaces prior to 
opening any leading connections. That way it won't negotiate beyond the
capabilities of any of its individual interfaces.

Dave