Re: [PATCH v4 00/18] PCI/P2PDMA: Fix ACS egress control handling

[Leon Romanovsky]

On Mon, Aug 24, 2026 at 08:22:50PM -0300, Jason Gunthorpe wrote:
> > PCI P2PDMA treats any enabled ACS P2P Egress Control bit as an upstream
> > redirect. PCIe r7.0, sec 6.12.3, table 6-11 says the Egress Control
> > Vector bit for the target port decides instead: a clear bit routes a peer
> > request directly, regardless of P2P Request Redirect. Firmware can
> > therefore enable Egress Control with a permissive vector while Linux
> > incorrectly rejects a valid direct P2P path.
> 
> I've never seen anyone use the egress control vector and broadly Linux
> doesn't support it. The ACS command line shouldn't enable "P2P Egress
> Control Enable" for this reason.

I tried to follow the PCI specification as closely as possible here, but
of course I always welcome the idea of eliminating one of the paths.

> 
> It is not a bad thing to accommodate the egress vector when improving
> the ACS logic, but the main stream usage is the interaction of the
> other bits along with ATS & RO in the TLP. See the comment I left a
> long time ago:
> 
> https://elixir.bootlin.com/linux/v7.2/source/drivers/infiniband/hw/mlx5/mlx5_ib.h#L1649
> 
> So it would be nicer to read in the commit message how the mainstream
> stuff is fixed up and just a little bit about egress control.

I will split the series into bug-fix patches and code improvements.
This should also help describe the purpose of the series more clearly.

> 
> > [ ... 36 lines skipped ... ]
> > A pre-existing gap comes first. The routing analysis covers only Requests
> > carrying an Untranslated address; ACS Direct Translated P2P overrides
> > those controls, so that scope is now written down rather than implied.
> 
> What I talked about with Thomas is we probably need the P2P subsystem
> to know what kind of TLP the driver intends to put here when doing the
> evaluation: strict order, relaxed order and translated all have
> different possible routing options, and real system configure things
> so each one takes a different path :\
> 
> Currently I think the P2P subsystem is assuming strict order
> non-translated TLPs when it makes its calculations. Which is fine, but
> as we go toward enhancing this each of the different paths should be
> kept seperate.
> 
> I don't know how the driver facing API should work, but at least real
> devices have options to use ATS or not, use RO or not, and can make
> use of information from the P2P subsytem to make the right choice.

Do you see a function like mlx5_umem_needs_ats() being implemented as part of
the PCI P2P logic?
https://lore.kernel.org/all/4-v1-bd147097458e+ede-umem_dmabuf_jgg@xxxxxxxxxx/

> 
> Further, when we get to things like an ACPI description of this stuff,
> it would be nice to still discover these differences as well.
> 
> -- 
> Jason