From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25EC2D6B6DC for ; Wed, 30 Oct 2024 22:07:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A7D4610E806; Wed, 30 Oct 2024 22:07:42 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="pymgKQqx"; dkim-atps=neutral Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by gabe.freedesktop.org (Postfix) with ESMTPS id BE14E10E806; Wed, 30 Oct 2024 22:07:41 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D1679A435A6; Wed, 30 Oct 2024 22:05:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2195DC4CECE; Wed, 30 Oct 2024 22:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730326060; bh=FGBXaMTs0zoZtuIJw76pQkmdmDElPzZuxay8K6IRs+M=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=pymgKQqxDWszTJEoGeU8SOxQXzSUDVj057M2/sGjtLFYJttHMz/9aSEyG9uEWshEx BZOsy13EfwLb3MxEWqHyDkKiERyJ7dN/vrGPYzUfkAIISMXHt65w6YgmNg3PWBRi3M jo4aN5OxjQ9jf+Nqo3Dd6a3LL+gTrg4tYNFL/yNQjWtny7MhIoBc11YHSs4a8nXt0i Ya2zIbvL8QOMwLzkZrrxkXkBLOLjS/gs0Ps8vu7HAzSG5YOAMfF5E11fIMtqnQGoDq ugDndL4kZm7pvqCaoQAiBV9DY3wxrlMa/cHBqAqpxeNXoqMo5nlRXkwyB/BaYRXNlx gwGxXiMQUL2yA== Date: Wed, 30 Oct 2024 17:07:38 -0500 From: Bjorn Helgaas To: Logan Gunthorpe Cc: "Kasireddy, Vivek" , "dri-devel@lists.freedesktop.org" , "intel-xe@lists.freedesktop.org" , Bjorn Helgaas , "linux-pci@vger.kernel.org" Subject: Re: [PATCH v2 1/5] PCI/P2PDMA: Don't enforce ACS check for functions of same device Message-ID: <20241030220738.GA1221922@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e146e2f-5d7c-4f28-b801-360795b4cae7@deltatee.com> X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Wed, Oct 30, 2024 at 03:20:02PM -0600, Logan Gunthorpe wrote: > On 2024-10-30 12:46, Bjorn Helgaas wrote: > > On Fri, Oct 25, 2024 at 06:57:37AM +0000, Kasireddy, Vivek wrote: > > In the PCIe world, I don't think a TLP can "loop back" to another > > function on the same device. > > I'm not sure if the spec says anything that specifically denies this. I'm not a hardware guy and I don't know if there's a direct statement about it, but if a Downstream Port supports ACS, it must support ACS P2P Request Redirect (PCIe r6.0, sec 6.12.1.1), which specifically applies to peer-to-peer TLPs. If peer-to-peer TLPs appear on the link, the Downstream Port will see them and act on them, e.g., either route them upstream (if P2P Request Redirect is enabled) or back downstream. I don't think the VF could act on them directly via a loopback path because that would lead to duplicate writes and duplicate Completions for reads. > But it seems to me that it would be possible for a multifunction device > to handle a transfer to a neighbouring function internally and not > actually involve the PCIe fabric. This seems like something we'd want to > support if and when such a device were to be created. If peer-to-peer transactions are handled internally, an SR-IOV device other than an RCiEP is required to support ACS with P2P Egress Control (sec 7.7.11) and P2P Request Redirect (sec 7.7.11.2). Bjorn