TLP Maximal Payload Size

Post a reply

Confirmation code
Enter the code exactly as it appears. All letters are case insensitive.
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:
BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON
Topic review

Expand view Topic review: TLP Maximal Payload Size

Re: TLP Maximal Payload Size

Post by support »


Let's first look what lspci -vv gave me on a Linux machine (I've out the part related to the Ethernet controller)

03:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet (rev c0)
Subsystem: Giga-byte Technology Unknown device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 4 bytes
Interrupt: pin A routed to IRQ 40
Region 0: Memory at fdcc0000 (64-bit, non-prefetchable) [size=256K]
Region 2: I/O ports at bf00 [size=128]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
Address: 00000000fee0200c Data: 4151
Capabilities: [58] Express Endpoint IRQ 0
Device: Supported: MaxPayload 4096 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <4us, L1 unlimited
Device: AtnBtn+ AtnInd+ PwrInd+
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [6c] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [180] Device Serial Number ff-65-6f-1c-f0-aa-32-ff

So it's quite clear that the device is capable of a TLP much bigger than what is actually used. But this is what the BIOS picked during enumeration, most likely based upon the limitation of the memory controller (to which the PCIe is connected on this machine).

Why computer hardware doesn't support TLPs longer than 128 bytes is another question. I suppose it's not considered worth to save the overhead. I mean, they could work hard to raise the TLP to 256 and save a little piece of overhead, and then PCIe jumps generation and doubles the speed.

And I also suppose that if a certain motherboard would support 256 bytes, and the effective TLP payload size would rise, some buggy PCIe cards would reveal the bugs that were hidden before. People would obviously blame the motherboard for being buggy, since the same card works on all other boards and not on that specific one. Now go explain who's fault it is.

So it I would be a motherboard manufacturer, I would stick to 128 bytes of max payload. I suppose the real manufacturers follow this logic.

You can, of course, try to raise the TLP size on a device with a tool like setpci. I suppose each device will react differently with each motherboard, if it will make any difference at all.


TLP Maximal Payload Size

Post by Guest »

Hello Eli,

I just came across your blog post about TLP maximal payload size. In examples such as yours, when the device can support more than what it is configured in DevCtl registers, is it possible to reconfigure it to another value? Probably by simply writing the value into the register?

Plus, why a device should not use its maximal TLP size? Is it possibly caused in training phase by an endpoint with lower supported max TLP size?