RE: iscsi : DataPDULength can differ in each direction.

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

>     Before you go ahead and spend time and energy on this I would just
> like to re-iterate my concerns that in practice few, if any,
> implementations will support asymmetric PDU sizes.
> 
> 	If, for example, a software initiator indicates a max PDU size of
> 128k and a hardware target indicates 8k, do we really think the target
> will ever send a 128k PDU? 

You can count on it. Fibre Channel works that way today and if allowed 
iSCSI will as well.

> I don't believe it will. The supporting
> argument seems to be predicated on the fact that the buffer management
> changes needed to make this happen are trivial. However, if an
> implementation can chain buffers together on transmit to build PDUs
> larger than the maximum size offered why can't it do so on receive?
> And if it can do so on receive why would it ever offer a maximum lower
> than the real maximum it can support?

Because the receive is doing direct placement and the transmit side is not.
Efficient direct placement works best with small PDUs. The transmit side
could care less.

> 	As an aside, I think this change might create something of a headache
> for sniffers since they now have to buffer the larger of the offered
> sizes instead of the smaller.

I haven't heard the Fibre Channel analyzer folks complain about assymetric
frame sizes.

> 	I agree that asymmetric PDU sizes seem beneficial but I have a very
> hard time believing we'll see any implementations that can take
> advantage of this feature. I also think the benefit might be
> relatively small and is probably not worth the level of spec change at
> this late stage.

On the contrary, I think this is a big win for the SW implementations. 
Header parsing accounts for a good deal of the receive side processing.
If that can be reduced it will free up CPU bandwidth on the SW side.

Dave