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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Aug 28, 2026 at 12:28:10PM -0400, Rodrigo Vivi wrote:
> On Thu, Aug 27, 2026 at 02:35:16PM +0200, Jiri Pirko wrote:
> > Mon, Aug 24, 2026 at 10:09:28AM +0200, ksinyuk@kernel.org wrote:
> > 
> > [..]
> > 
> > >Example queries using the in-tree YNL tool are:
> > >
> > >    $ ./tools/net/ynl/pyynl/cli.py \
> > >          --spec Documentation/netlink/specs/drm_fabric.yaml \
> > >          --dump fabric-get
> > >    $ ./tools/net/ynl/pyynl/cli.py \
> > >          --spec Documentation/netlink/specs/drm_fabric.yaml \
> > >          --dump endpoint-get --json '{"fabric-id": <id>}'
> > >    $ ./tools/net/ynl/pyynl/cli.py \
> > >          --spec Documentation/netlink/specs/drm_fabric.yaml \
> > >          --do port-get --json '{"endpoint-id": <id>, "port-index": 0}'
> > 
> > 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.
> 
> Please notice that this bubble was already broken. Netlink design
> always had the dream to replace ioctl everywhere. And there are already
> other usage in place that are not network related.

Yeah, and people have been living with the friction, and some places
don't have quite the same complexity, but that doesn't mean it cannot
be improved. :)

For something complex like this, if you can't concretetly tie the HW
to a net namespace, and follow the net namespace rules for visibility,
then it is going to be a painful choice. I speak from alot of rdma
experiance where net namespaces have been consistently challenging.

> In our case we use the netlink API for GPU RAS error reporting: drm-ras.
> 
> Also there are other usages in netlink spec that apparently has nothing
> to do with networking, like energy...
> 
> And in this particular case here, the drm-fabric is a 'network' of
> GPU memory... At some point we even wondered if net/ was the right
> place for this common API....

net/ is mainly focused on IP networking, it is where you should be
putting the ethernet layer at the bottom of the ua link over ethernet,
SUE, or whatever. It is hard to imagine having an actual physical
ethernet network and claiming no implementation will ever need to
process ethernet packets or deal with ethernet phy.

There are so many variations of these "scale up" fabrics now, it would
probably be appropriate to have one subsystem that aims to work with
all of them. It is almost rdma but different enough it probably
wouldn't fit well.

Certainly redoing all that ethernet related stuff in drm or, worse, in
amdgpu, is a pretty ugly idea.

Jason