Re: [PATCH v9 07/18] PCI/P2PDMA: Answer routing per TLP class

[Bjorn Helgaas]

On Thu, Oct 01, 2026 at 02:55:15PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@xxxxxxxxxx>
> 
> calc_map_type_and_dist() returns one mapping type per provider and client,
> valid only for strictly ordered Requests carrying an Untranslated address.
> Clients that use Relaxed Ordering or ATS cannot ask what the fabric would
> do with their traffic.
> 
> Add enum pci_p2pdma_tlp_flags to name a class and pci_p2pdma_map_type_tlp()
> to ask about one. The topology walk and the ACS Control reads do not depend
> on the class, so decide all of them from the one walk and cache them
> together, four bits each. Every class still answers alike; the controls
> that tell them apart come next.
> 
> Tested-by: Tushar Dave <tdave@xxxxxxxxxx>
> Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx>
> ---
>  drivers/pci/p2pdma.c | 159 +++++++++++++++++++++++++++++++++++++++++----------
>  1 file changed, 128 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index 841c86be31bb..43e225cc5735 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -492,6 +492,33 @@ static struct pci_dev *find_parent_pci_dev(struct device *dev)
>  	return NULL;
>  }
>  
> +/**
> + * enum pci_p2pdma_tlp_flags - Properties of the TLPs a client will issue
> + *
> + * These describe the traffic rather than the topology, and select which ACS
> + * controls apply along the peer-to-peer path. A value of 0 means strictly
> + * ordered Requests carrying an Untranslated address.
> + *
> + * @PCI_P2PDMA_TLP_TRANSLATED: Requests carry an ATS Translated address. PCIe
> + *	r7.0 sec 6.12.3 routes those to the peer regardless of ACS P2P Request
> + *	Redirect and ACS P2P Egress Control wherever ACS Direct Translated P2P
> + *	is enabled.
> + * @PCI_P2PDMA_TLP_RELAXED_CPL: The provider returns Completions with the
> + *	Relaxed Ordering attribute set. PCIe r7.0 sec 6.12.1.1 never redirects
> + *	those, so ACS P2P Completion Redirect does not gate the path. The
> + *	Completer chooses this attribute and the specification does not require
> + *	it to copy Relaxed Ordering from the Request into the Completion, so a
> + *	caller passing this flag asserts that its provider does.

It doesn't sound right to me that Completers choose the attribute.  I
thought *Requesters* chose the RO attribute based on their design
(knowledge about which transactions require strong ordering) and their
Enable Relaxed Ordering bit.  Sec 2.2.9.1 says:

  - Completion headers must supply the same values for the Attribute
    as were supplied in the header of the corresponding Request,
    except as explicitly allowed:

    - when IDO is used (see § Section 2.2.6.4)

    - when RO is used in a Translation Completion (see § Section
      10.2.3)