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

[Konstantin Sinyuk]

On Thu, Aug 27, 2026 at 02:35:16PM +0200, Jiri Pirko wrote:
> Using generic netlink instead of sysfs for this makes a lot of sense,
> but it may be a bit odd to use it outside the networking area.
> I've been struggling with the same in another non-networking use-case
> as well.

Agreed, and the series shows the friction. The namespace handling is
nominal, and CAP_NET_ADMIN as the mutation gate is another borrowed
part of the model. I went into that in more detail in the reply to
Jason.

> - One character device per registered instance, not one global family.
>   Access control is the file: udev rules, ACLs, an fd passed into
>   a container.

The fd-based access and event model addresses real problems with one
global family and one multicast group.

The main question is what the CTLV instance would represent. A fabric
can span multiple devices and has its own lifetime. An endpoint can also
be detached from a fabric with fabric-id 0 and continue to exist. A
character device per accelerator would not provide the same global view
as the current family.

Can a CTLV instance represent a multi-device fabric or the global
fabric registry rather than one physical device?

> Would this make sense to use for you?

In principle, yes. I cannot base this series on an out-of-tree pre-RFC,
but the fabric, endpoint, port and peer model is separate from the
current serialization.

Changing transports would be more than regeneration, so I will read the
draft before saying more.

Thanks,
Konstantin