From: Jason Gunthorpe <jgg@nvidia.com>
To: Konstantin Sinyuk <ksinyuk@kernel.org>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
Jiri Pirko <jiri@resnulli.us>,
dri-devel@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Francois Dugast <francois.dugast@intel.com>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Donald Hunter <donald.hunter@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Ilia Levi <ilia.levi@intel.com>,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
jhs@mojatatu.com
Subject: Re: [RFC PATCH 0/12] drm/fabric: vendor-neutral topology infrastructure for scale-up accelerator interconnects
Date: Mon, 31 Aug 2026 09:23:41 -0300 [thread overview]
Message-ID: <20260831122341.GG4157646@nvidia.com> (raw)
In-Reply-To: <fabric-jason-reply.1788176463.ksinyuk@kernel.org>
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
next prev parent reply other threads:[~2026-08-31 12:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 8:09 [RFC PATCH 0/12] drm/fabric: vendor-neutral topology infrastructure for scale-up accelerator interconnects Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 01/12] drm/fabric: add core object model and provider API Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 02/12] drm/fabric: add query uAPI and generated headers Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 03/12] drm/fabric: implement query netlink operations Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 04/12] drm/fabric: add read-only synthetic provider Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 05/12] drm/fabric: add object-model KUnit tests Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 06/12] drm/fabric: add YNL query and policy selftests Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 07/12] drm/fabric: add topology-provisioning core Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 08/12] drm/fabric: add provisioning netlink uAPI Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 09/12] drm/fabric: implement mutation netlink operations Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 10/12] drm/fabric: make the synthetic provider writable Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 11/12] drm/fabric: add mutation KUnit tests Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 12/12] drm/fabric: add mutation netlink selftests Konstantin Sinyuk
2026-08-26 9:32 ` [RFC PATCH 0/12] drm/fabric: vendor-neutral topology infrastructure for scale-up accelerator interconnects Leon Romanovsky
2026-08-26 15:38 ` Konstantin Sinyuk
2026-08-27 17:09 ` Leon Romanovsky
2026-08-28 16:13 ` Rodrigo Vivi
2026-09-01 11:01 ` Leon Romanovsky
2026-09-01 15:25 ` Rodrigo Vivi
2026-09-02 7:10 ` Leon Romanovsky
2026-08-31 11:45 ` Konstantin Sinyuk
2026-08-27 12:35 ` Jiri Pirko
2026-08-28 16:28 ` Rodrigo Vivi
2026-08-28 17:03 ` Jason Gunthorpe
2026-08-31 11:45 ` Konstantin Sinyuk
2026-08-31 12:23 ` Jason Gunthorpe [this message]
2026-08-31 11:45 ` Konstantin Sinyuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260831122341.GG4157646@nvidia.com \
--to=jgg@nvidia.com \
--cc=airlied@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=edumazet@google.com \
--cc=francois.dugast@intel.com \
--cc=horms@kernel.org \
--cc=ilia.levi@intel.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=ksinyuk@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=skhan@linuxfoundation.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox