Re: [PATCH for-next] RDMA/efa: Expose device P2P DMA support via device query

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Oct 07, 2026 at 09:01:36AM +0000, Michael Margolin wrote:
> On Fri, Oct 02, 2026 at 11:52:41AM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 01, 2026 at 06:53:33PM +0300, Leon Romanovsky wrote:
> > 
> > > > Looked at Leon's patches and it does seem like the right place to expose
> > > > such peer relations. Although it wouldn't help with our immediate need,
> > > > maybe we can add a sysfs interface on top of Leon's patches to expose
> > > > the gathered accessiblity (and maybe also performance) information.
> > > > 
> > > > Leon, what is your opinion on this?
> > > 
> > > ACPI tables are available here /sys/firmware/acpi/tables/, this will
> > > include our new p2p HMAT extension.
> 
> I was iterating over Jason's idea and what I imagine is an interface
> that contains already parsed data at PCI level, like:
> 
> /sys/firmware/acpi/p2p/
> ├── 0000:55:00.0/          # RDMA NIC
> │   ├── 0000:59:00.0/      # → GPU (reachable peer)
> │   │   ├── latency_ns     # 200
> │   │   └── bandwidth_mbs  # 32000
> │   └── 0000:5a:00.0/      # → GPU (reachable peer)
> │       ├── latency_ns     # 200
> │       └── bandwidth_mbs  # 32000
> │
> ├── 0000:59:00.0/          # GPU
> │   ├── 0000:55:00.0/      # → RDMA NIC (reachable peer)
> │   │   ├── latency_ns     # 200
> │   │   └── bandwidth_mbs  # 32000
> │   └── 0000:56:00.0/      # → RDMA NIC (reachable peer)
> │       ├── latency_ns     # 200
> │       └── bandwidth_mbs  # 32000
> │
> ├── 0000:9a:00.0/          # NVMe
> │   └── 0000:55:00.0/      # → RDMA NIC (reachable peer)
> │       ├── latency_ns     # 300
> │       └── bandwidth_mbs  # 12000
> 
> > 
> > ACPI is nice and general, but..
> > 
> > Doesn't AWS have something already to convay VM instance type
> > configuration information? That's pretty normal these days isn't it?
> 
> There is but both options doesn't help in the short term and long term I
> think, as you mentioned, that ACPI is a more general solution and it
> doesn't require any additional dependencies.

Perhaps you can disable dmabuf support entirely in your driver based
on this firmware flag. It is weird, but less objectionable than new
ABI points talking about P2P.

Your userspace can probe if dmabuf support is enabled without having
to do cuda.

Jason