> On Tue, 2011-09-06 at 12:12 -0700, Jon Mason wrote: >> > Are these typically hitting with the "performance" option ? IE. It >> make >> > sense to leave MRRS untouched in the "safe" case. >> >> The patch I sent out still used the "performance" option without >> modifying the default MRRS of the device. All that have tested it >> said that it resolves their issues. > > But that will cause other issues as I described, if the MRRS end up > larger than the MPS. IE. The MRRS of a device must be set to be lower or > equal to the MPS of that device (not of the parent btw) if we allow the > parent(s) to have a larger MPS. I don't think so. Just looking into my lspci I found more than one occurence of things like this: MaxPayload 128 bytes, MaxReadReq 512 bytes Which is perfectly fine. The requester (i.e. the device) may issue read requests up to 512 bytes at once, which is a thing about transfer credits and the like (IIRC). The completer may split the completions into packages of any valid size between the minimum size (IIRC 64 bytes) and the maximum _payload_ size the requester can handle. In this case you will likely get either 8*64 or 4*128 byte completions for a read request of 512 byte, but any combination in between would be valid, too. One needs to keep in mind that a read request of 512 byte is itself only a 12 or 16 byte packet, so it isn't affected by the payload size at all. > I -did- hit a very real problem with adapters where that wasn't true. >From my understanding this shows that these adapters were broken, nothing else. An adapter must be prepared to get a bunch of smaller packets anyway, as it has no control of how the completer sends out the data. So maybe your adapters just got screwed by awaiting a 512 byte reply and getting 4*128? You could connect them to some sort of bastard completer if you have one (I don't) that completes every request in packets of 64 byte and see if they will not even explode with 128 byte MRRS. Eike -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
