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

[Jason Gunthorpe]

On Mon, Aug 31, 2026 at 02:45:05PM +0300, Konstantin Sinyuk wrote:
> On Fri, Aug 28, 2026 at 02:03:01PM -0300, Jason Gunthorpe wrote:
> > 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.
> 
> Agreed. The series does not provide meaningful namespace semantics; it
> is host-global and confined to init_net. I would rather make that scope
> explicit than invent per-netns fabric semantics that the hardware does
> not have.

For namespaces and permissions you need to decide on a granual of
control. For something like this is probably one of:
 - Whole machine/subsystem/fabric
 - Per ASIC / end point
 - Per ethernet port

I would kind of broadly guess you'd have one cdev for each fabric and
one cdev per asic or port...

Then you could shove a fabric into a container sensibly..

> against. I would not switch transports based on an early pre-RFC, but I
> no longer consider the transport choice settled.

It is a good moment to collaborate with Jiri so it can work out for
this use case too.

> Switches are the difficult case. A UALink switch is not a DRM device,
> and complete Pod topology may involve information owned by the Pod
> Controller and switch-management plane, not only accelerator drivers.
> If that information has to be represented as first-class objects, DRM
> may not be the right final home.

Well this series looks like it is all about telling the kernel the
routing and address map to presumably program into the HW. I guess
there is a bunch more to actually do the network trafic to get the
routing in the first place and some userspace to bridge beween the
on-link protocol and the the kernel objects?

Then there is probably another big swath to get metrics and monitoring
out of the end ports..

Jason