Arne Redlich <arne.redlich at googlemail.com> writes: > No. And in fact even hardwiring it to 8k could potentially lead to > problems already, it's just very unlikely. Indeed. However, it should clearly be allowed to grow at least to MaxRecvDSL in size. E.g. for our initiators, we have discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 262144 Where would I find the the initiator declaring its MaxRecvDSL for the purposes of discovery? If I can store and get at the value during text_key_add, it should be trivial to arrange for the realloc to be capped at MaxRecvDSL, and drop keys only beyond that point. Meanwhile, I'm going to have to leave it reallocing in my tree for now as that's the only way I get a usable target daemon. Presumably this is also true for anyone else trying to use tgtd for a non-trivial number of targets so it might be worth adding a clear warning to the documentation? > As I wrote before: to get it right (i.e. support an arbitrarily long list > of targets), the data must be split into several PDUs, each having a max > size of the MaxRecvDSL the initiator declared. And sequencing of these > PDUs is also different from SCSI Data In's, i.e. the first text rsp is > sent with a tag indicating there is more data, and the initiator can then > choose to request the next part of the response with another text request. This is significantly more implementation work, albeit the more general solution as you say. (I can't bring myself to say 'right solution': this degree of mechanism complexity for sending a straightforward list of targets over a TCP connection is truely insane! How did iSCSI become so hideous?) I don't have the time to try to tackle it. Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html |