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.
