Re: [PATCH V3 0/5] PCI: Re-evaluate DEV3 14-Bit Tag Requester Enable on link mode changes

[Lukas Wunner <lukas@wunner.de>]

On Sat, Aug 15, 2026 at 01:46:16AM +0530, Vidya Sagar wrote:
> DEV3_CTL.14-Bit Tag Requester Enable is only meaningful while the link
> operates in Flit Mode.  In Non-Flit Mode the upper tag bits are not
> transmitted on the wire, so a requester that still has it set emits
> requests whose completions it can no longer match: the completer does
> answer, but the completion comes back with the upper tag bits zero.

Please include a pointer to the spec section.  Looking through
PCIe r7.0 sec 2.2.6.2.1, I don't quite see anything that says
"14-Bit Tag Requester Enable is only meaningful [...] in Flit Mode".

It does say:
"A Function that supports Flit Mode must support 14-Bit Tag Completer
capability"

But that's different from what you're claiming.

It also says:
"In Non-Flit Mode, Tag[8] and Tag[9], are not contiguous with other Tag
field bits in the TLP Header. These bits were Reserved prior to 10-Bit
Tags being architected. Requesters in Non-Flit Mode that do not support
10-Bit Tag Requester capability must set Tag[9:8] to 00b."

Also not quite what you're claiming.

So where is this coming from?

I think if the link reverts to Non-Flit Mode and 14-Bit Tags were
only meaningful in Flit Mode, then the hardware should automatically
stop using 14-Bit Tags.  Relying on software to clean up a protocol
inconsistency before issuing further requests seems dangerous and silly.

Thanks,

Lukas