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

[Leon Romanovsky]

On Fri, Oct 09, 2026 at 04:25:29PM -0500, Bjorn Helgaas wrote:
> 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)

You are right, while the code is correct and we indeed expects from
"Requester" to chose, the comment is not correct and needs to be
changed.

Thanks