Re: [RFC PATCH 0/12] drm/fabric: vendor-neutral topology infrastructure for scale-up accelerator interconnects

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Aug 27, 2026 at 08:09:11PM +0300, Leon Romanovsky wrote:
> On Wed, Aug 26, 2026 at 06:38:58PM +0300, Konstantin Sinyuk wrote:
> > On Wed, Aug 26, 2026 at 12:32:22PM +0300, Leon Romanovsky wrote:
> > > Tell your AI that this is not how things work in the real world. The chances
> > > of multiple hardware implementations fitting a software model designed
> > > without considering the actual hardware are effectively zero. This is why
> > > successful subsystems have emerged from consolidating support for multiple
> > > existing hardware implementations.

Right, but we also have to tell AI that the real world is much more complicated
than this. When various vendors already had multiple different implementations
in place, they will refuse to consolidate... like you stated yourself below:
"which is unlikely to be ported to this new framework"

Perhaps what we missed to tell AI is to add a clear statement that this
is an RFC for future. To discuss the design in advance so when the real
hardware starts to appear perhaps we have a chance of moving things to a
consolidated vendor-agnostic API that fulfills the need of the vendor-agnostic
UALink design.

> > 
> > Fair point. The simulator validates the implementation, not whether the
> > abstraction fits real hardware.
> > 
> > The model was shaped by the public amdgpu xGMI implementation, and the
> > cover letter asks AMD whether it covers their requirements. It still
> > needs validation against production implementations, and the read-only
> > milestone will not be proposed for merge without a production provider.
> > I will fix the wording in the next revision.
> 
> The wording alone is not sufficient. Your proposal should be backed by
> real devices representing different architectures from different
> vendors.

Future Intel (and other vendors) hardware will include UALink.
Please notice this is an RFC to discuss the viability and design for when
these devices start to appear.

> 
> The current proposal is based on a single implementation, which is
> unlikely to be ported to this new framework in the foreseeable future.
> The amdgpu xGMI implementation already exposes the required UAPI through
> sysfs and would need very strong incentives to abandon its "legacy"
> users in favor of this new netlink interface.
> 
> The last new subsystem I am aware of was introduced with implementations
> from three different vendors to demonstrate its robustness. You should
> probably aim for a similar level of coverage here.

If we wait 3 different devices to show-up before we can start discussing
a common API, then it might be way too late.

But of course, we can definitely move this netlink as is to inside
drivers/gpu/drm/xe and call it xe_fabric and if someone else is interested
in join effort we move that outside.

Thanks,
Rodrigo.

> 
> Thanks
> 
> > 
> > Thanks,
> >  Konstantin.