On Sat, Jan 9, 2010 at 6:16 PM, David Dillow <[email protected]> wrote: > > On Sat, 2010-01-09 at 14:05 +0100, Bart Van Assche wrote: > > The SRP spec says that the target must specify the maximum message > > size in the SRP_LOGIN_RSP information unit. The largest value one can > > set the srp_sg_tablesize initiator parameter to is (max. SRP message > > size defined by the target - 68) / 16. With older SCST-SRPT revisions > > the maximum SRP message size was 996 bytes, hence a maximum of 58 for > > srp_sg_tablesize. With newer SCST-SRPT revisions the maximum message > > size defaults to 2116, which corresponds to a maximum of 128 for > > srp_sg_tablesize. > > I see, thanks for the reminder. It's been a while since I've had to deal > with that part of the spec, and I've been fortunate that all of the > vendors I work with have max message sizes that allow 255 entries. > > Does SRPT support the RDMA'ing the indirect buffer descriptors from the > Initiator such that it isn't constrained by the partial memory > descriptor list in the command request? The initiator restricts itself > to 255 SG entries because I've not found a target that implemented the > spec fully, though it'd be nice to be able to guarantee the ability to > send larger request sizes. I think this will also become important for > running bidirectional commands, since the room for descriptors cached in > the command is shared for both directions.
At this time SRPT only supports indirect buffer descriptors that are present entirely in the command request. Regarding the number of SG entries: I'm not sure that I understand why you want to be able to send SG-lists containing more than 255 SG entries. In the tests I have run the throughput gain resulting from SG list sizes above 128 was marginal (a few percent). Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
