> But each shows a Max_Payload_Size of 128 bytes in both the DevCap and > DevCtl registers. Clearly they are accepting 256-byte payloads, else I > wouldn't notice the big perf improvement when reading data from the > disks.
Right -- you'd see errors instead. > Could it be possible that (1) an errata in the AMD690G makes its > DevCap register incorrectly report Max_Payload_Size=128 even though it > supports larger ones, and that (2) the AMD690G implements PCI-E > leniently and always accepts large payloads even when it is not > supposed to when DevCtl defines Max_Payload_Size=128? Looking at the AMD 690 series manual (well, the family register guide), the max payload size value is deliberately set to 0 to indicate that the chip only supports 128-byte transfers. There is a bit in another register which can be set to ignore max-payload errors. Perhaps that's being set? I can guess as to why it might accept a 256-byte transfer even when it's not truly supported. Perhaps there is a 512-byte buffer on the chip, for instance, between the PCI-E interface and the rest of the chip. If there is a flag to indicate when at least 128 bytes are available, then the chip would allow an incoming transfer whenever there's room for that 128 bytes. If the memory subsystem is not under contention, data would quickly flow out and make room for more. If the system were under heavy load, the internal buffer might wind up with, say, 384 bytes of data waiting to be stored into memory -- and if the chip allowed a new transfer to start (since there were 128 bytes free in the buffer) and received 256 bytes of data, it would drop some, or hang. > I came to the same conclusion as you after grepping through the code. Someone should add proper PCI-E payload size support. ;-) This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
