arne.redlich@xxxxxxxxxxxxxx wrote on Tue, 09 Jun 2009 18:22 +0200: > Currently the iSCSI driver only solicits MaxXmitDSL(!) bytes with each R2T, > although it could solicit MaxBurstLength bytes. This fix makes sense. R2T should ask for a whole burst. > This was introduced with the iSER driver and a RDMA_TRANSFER_SIZE constant to > limit the size of RDMA transfers. However, MaxBurstLength can and should be > used for that. But RDMA should not necessarily use MAX_BURST for its data transfer sizes. This size is completely controlled by the target and not even visible to the initiator. The initiator should not be involved in the negotiation of the size. There was a longish discussion of this value in the archive somewhere around the time iser was getting added to tgt. Unfortunately I don't have gear to test this anymore. One risk is that iser initiators will negotiate a small MaxBurstLength and get bad performance. Another is they negotiate something bigger than the mempool_size constant and break the iser code, if someone tries to set target's MaxBurstLength bigger hoping for faster transfers. If you want to be safe, you can leave data_inout_max_length alone. Just change iscsi_r2t_build to "if (rdma)" to select max_burst or data_in_out_len. If I know Fujita code style, he won't like the "if (rdma)" you added here or the one I'm suggesting. In which case you might add a second conn parameter, data_r2t_max_length, that gets set appropriately. And rename data_inout_max_length to remove the "in" part now that you've figured out the R2T situation. -- Pete -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
