On 6/11/2014 12:17 AM, Quinn Tran wrote: <SNIP>
QT> Instead of using existing value within cmd->data_length, can we calculated data_length based on secstors & blocksize. cmd->data_length = sectors * dev->dev_attrib.block_size;
We can do that I suppose... Although it seems weird that the core discards the transport byte-count... Just wandering if we should recalc on the DIF case only or always.
From the QLogic perfective, the cmd->data_length is pull directly from the wire (i.e. FCP header) when cmd is received. In essence, it's whatever the Initiator is set it to. We does not have any indicator to spot DIF vs none-DIF cmd when 1st received, unless the code do a peek.
Same for all transports I assume...
With that said, the cmd->data_length does not guarantee to contain both "data length" & "protection length" when cmd is submit to TCM/target_submit_cmd(). In Dif-Insert mode, data_length will only contain the actual data(no Dif).
No, in the DOUT_INSERT/DIN_STRIP case, protect bits are off and the core will take the data length as is.
This case is covered.
It's best that the SBC code re-calculate the actual data length and dif data length based on the number of sectors derived from the cmd.
Nic, what's your take on this? Sagi. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
