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

[Rodrigo Vivi]

On Tue, Sep 01, 2026 at 02:01:20PM +0300, Leon Romanovsky wrote:
> On Fri, Aug 28, 2026 at 12:13:28PM -0400, Rodrigo Vivi wrote:
> > 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:
> 
> <...>
> 
> > > 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.
> 
> I guess that, like most of us, you are not authorized to discuss or
> comment on Intel's non-public roadmap. Can you point to any public
> commitment from Intel to implement UALink in its devices?

That's the only public support commitment you will find for now:

https://ualinkconsortium.org/blog/intel-supports-ualink-for-scale-up-networking-829/

as an active member of the consortium
https://ualinkconsortium.org/members/

> 
> I couldn't find one.
> 
> <...>
> 
> > > 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.
> 
> We are not talking about "waiting for", but about "being backed by".
> The general kernel rule is that the second implementation is responsible
> for consolidating the code. XE appears to be that second implementation.

Again, this is an RFC, not a merge request. The goal is to do it right
from beginning rather than facing years of churn after things are already
implemented so differently by downstream solutions.

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