Re: [PATCH RFC 0/1] Add AtomicOp Requester support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2015-09-21 17:46, Bjorn Helgaas wrote:
On Mon, Sep 21, 2015 at 03:44:59PM -0500, Jay Cornwall wrote:
On 2015-09-14 14:58, Bjorn Helgaas wrote:

>00:1c.0: PCI bridge to [bus 01-04] Root Port, with AtomicOp Routing
>01:00.0: PCI bridge to [bus 02-04] Upstream Port, with AtomicOp Routing
>02:00.0: PCI bridge to [bus 03] Downstream Port, with AtomicOp Routing
>03:00.0: endpoint AtomicOp Completer Supported
>02:00.1: PCI bridge to [bus 04] Downstream Port, with AtomicOp Routing
>04:00.0: endpoint no AtomicOp Completer support
>
>It's true that we wouldn't want to enable AtomicOp routing to 04:00.0,
>but isn't that what the AtomicOp Egress Blocking bit is for? If we
>set that in 02:00.1, we should be safe in the sense that AtomicOps
>targeting 04:00.0 should cause non-fatal errors.

If 02:00.1 had egress blocking then, if I understand correctly, a
00:1c.0 -> 04:00.0 AtomicOp request would be blocked.

Yes, a 1c.0 -> 04:00.0 AtomicOp request would be blocked, but 04:00.0
doesn't support AtomicOps, so we *want* that request to be blocked,
don't we?  If 04:00.0 received an AtomicOp, I think it would handle it
as a Malformed TLP, which by default is a Fatal Error.

I think I was confused by your earlier comment:

>I assume the common usage scenario is to enable AtomicOps for
>host-to-device and/or device-to-host transactions, and we can ignore
>device-to-device transactions for now.

00:1c.0 -> 04:00.0 would be the host-to-device scenario. It's true that 04:00.0 does not support AtomicOp completion in the above example. However, enabling AtomicOp requests for 04:00.0 would cause egress blocks to be set in the 00:1c.0 -> 03:00.0 path.

Our immediate use case for AtomicOps is indeed device-to-host, and I expect this is the most common case. I can make a V3 patch which explicitly supports this case only by setting egress blocks on downstream ports of upstream bridges.

This would guarantee that AtomicOp requests terminate correctly, at the expense of potential users of host-to-device or device-to-device scenarios.

--
Jay Cornwall
--
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



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux