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
