From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB18723E334 for ; Thu, 27 Aug 2026 12:35:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787834130; cv=none; b=fzKqR2hVFOuQ9Y5OcI4teMy6/qBXBh/zPTRHoQdsufu7C1kQLzHa0AVGDTKPfzKABfFfyF3RA84E1u+en6P+YhnC0srwUGa7DGPTGcIrNwngzgYnrJ9IV0NsM423uHCzVvLpYqKd1/JTEHg4t+9hY3IbVyjn/BN7yj+JF2XgAWI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787834130; c=relaxed/simple; bh=bmbiqdOCeZle1t8GhFHFgUaBjsvNdWoT+bkaG6Qn/FA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oiAOopEVkgjRXS9Gnb/+nnmX4F8b6UtVXeGYqHI1MFsXc7lM7QjjVZ48SJmr87RaSNW472cdfNIUQkeMhGOMIvy1mrgUTa9P8gaaYJzxfJfQBtluJVozmyFCZoTjC08S+GF7i9Nh3cWgREIOEkM5RV53eP1UQtaD+9olbil3qTM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=resnulli.us; spf=none smtp.mailfrom=resnulli.us; dkim=pass (2048-bit key) header.d=resnulli-us.20251104.gappssmtp.com header.i=@resnulli-us.20251104.gappssmtp.com header.b=HzxUP10U; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=resnulli.us Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=resnulli.us Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20251104.gappssmtp.com header.i=@resnulli-us.20251104.gappssmtp.com header.b="HzxUP10U" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-495437bb891so7322045e9.1 for ; Thu, 27 Aug 2026 05:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20251104.gappssmtp.com; s=20251104; t=1787834122; x=1788438922; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=FqMm8FT0UDvKvnU0PABnBSS+wYbc4aE8U5V+uRrPoww=; b=HzxUP10U4ZXwOcdfmkfuv5zV+yOdGKiFym6mZv2T3oNwYEnklHASsNatL0EbZKqqWq gagrP5NNJulSlGAXD4Tb5rHjHaLJyeaOiSCe3TXrScW4nklUZ49bOS2gKjVqSj3YnE3Z mDXdcYwnUXn4wfpzP7q4svINJvOWkDYUkryc7+JkopFkS87CLWtEkaOnV1rYAyJinLnU FvX+OYy4anL7SMmqQOlqWxwI3APBJxLKBztVI5wBGbWXPEGHu4sq0oWbOHAV0K3cbIem hRoOxoEN83nXbdie/L3T3pjQf6NDAvNSbSSOSwSwCfiDSWutRzQMBZm1l2n28Y5U8OPN /+1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787834122; x=1788438922; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=FqMm8FT0UDvKvnU0PABnBSS+wYbc4aE8U5V+uRrPoww=; b=WF5PZMp1UsRuIrNdOjmqMw0fIA/JD/SVWI+k6v6VLdSV0GH+Bf42CI0bJunCZHOk7/ /2kGOrp4mE3XhVi+5gCUb9ctSkNIdsTf9K+ctbmtY81RPqhShzgjbUHbZ/pL4G3lDIN4 qeX3thSZQAffGJmhuVLY0P/oxpGbKy1MSDjdAGEYmOwGMmYnHYOuNensrdQmCDnA1QvR JXwfXWys5US8F2PIGeHtw/jXx4P+uBl/Maw6t58qBnk+PnBpStc4kterJOfjmu0aJ3fz k/1WMjtomcl0n75z1KmXvCjaDPetv036rGanv0hcCqKzXhXRzMVbqr3FVRObq3cer5Ks MH1g== X-Forwarded-Encrypted: i=1; AHgh+Rp/GsrNSMLtC08LgrKMx30fIu3C1AUHEtzIdoa0xaSHWVSUEFfPe5LsHSqyJXs3kgUOL8zkE7VF/co=@vger.kernel.org X-Gm-Message-State: AFuF++lKAGcWyvWxdk0Zq2WfouxhnFSE3Dl8JU3CO0YEZKLBV6+QFN5i mx6pBibFn2xzDF43RMmjVvid9yqkydkcaw24PtunjZhXCq1FrQpFf8eBgH4spV+56pA= X-Gm-Gg: AR+sD12A18DtjmOmthTcxvkCshVH5sZ6BMEcUrwtijOX2hXdlePBSG4m6Ozzl0b/ek6 x/s7CVilGJOpDE+j1M2L+dQpaOzAn0XP1j+ww/NoMssmKXJzsRDo1PtEL6Hlbd08Rwe8blFxR+g Aa0iznjX0uWyoOu/t+Gc0xF6OcKpg0NN0J175p9/0+mIHIOOaz0brFhyriXslcmNRb/+cfAVx1Q tSXfm+ziYvQRlhddlgjDUjtZf94h+Wkn6Ew/pZtfQ0573PbUw92WhiF0mNtce+0eNqIQhbTYfd+ t1tiZ9WtcT6EXPiPW1NqTnFpHtp2KLun4tp1tUw+IcoRS3aTRCqYzAxvm/MYzkGNSjywyvL3mhw GVbDkA+F8EzSHknGylMcJbKPLsHF6r4s66sCt7p/qkbstRZwlvm++7j8mf0EWStPVXbCISwPe68 5N+C6kuGNbGE8fNv2YBwfOJXC/0eYzGeUMglIT6dE9fD7YRaktnhVXodgem/1bx4VSgs/+xqzRG FKQXIfA X-Received: by 2002:a05:600c:3e8e:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-49b0dfd7d2cmr84639315e9.7.1787834121595; Thu, 27 Aug 2026 05:35:21 -0700 (PDT) Received: from localhost ([140.209.217.211]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4a940aeasm46658765e9.10.2026.08.27.05.35.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 05:35:21 -0700 (PDT) Date: Thu, 27 Aug 2026 14:35:16 +0200 From: Jiri Pirko To: Konstantin Sinyuk Cc: dri-devel@lists.freedesktop.org, Maarten Lankhorst , Francois Dugast , David Airlie , Simona Vetter , Maxime Ripard , Thomas Zimmermann , Jonathan Corbet , Shuah Khan , Donald Hunter , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Ilia Levi , Rodrigo Vivi , linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jhs@mojatatu.com, jgg@nvidia.com Subject: Re: [RFC PATCH 0/12] drm/fabric: vendor-neutral topology infrastructure for scale-up accelerator interconnects Message-ID: References: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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": }' > $ ./tools/net/ynl/pyynl/cli.py \ > --spec Documentation/netlink/specs/drm_fabric.yaml \ > --do port-get --json '{"endpoint-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. I have been building a framework that keeps the benefits of generic netlink, extends it and is fd-based. I call it CTLV, here's a link to an early pre-RFC draft: https://github.com/jpirko/linux_mlxsw/commits/wip_ctlv_pre_rfc_draft1/ What are the benefits over generic netlink: - No networking in the dependency chain. No netlink sockets, no CAP_NET_ADMIN, and no network namespace semantics to reason about for a device that has none. - 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 open mode decides what is allowed - actions need write, queries need read - so there is no permission model to reinvent per family. - Events per open file description, not a multicast group. Each descriptor has its own subscriptions and queue, and an overflow is reported in-band: the next read returns an event-overflow record naming the first and last sequence lost and how many. - Large payloads are referenced, not copied. A blob attribute carries a user VA, a memfd and offset, or a dma-buf fd. Nothing big travels through the message. - One YAML specification, everything generated from it: kernel metadata, UAPI headers, userspace bindings and the reference documentation. Introspectio. is answered out of the same metadata the validator enforces, so a device cannot advertise an operation it will refuse. A checked-in ABI snapshot makes any wire change a reviewable diff. - Family inheritance. A family inherits another's operations and fills declared extension points. The effective schema is resolved per device and the chain is exposed to user. A shared core with per-driver extensions is declared once, and both attributes and operations can be extended. - Introspection is per-device and live. The framework answers three queries on every device: the family chain, one entry per published operation, and any operation's full attribute tree with its bounds and limits. The answer is what this device accepts right now, including what a vendor extension added to an inherited operation and whether an op is currently disabled, and op-changed events carry the generation ops-dump reports, so a dump can be ordered against a change. GETFAMILY and GETPOLICY describe a family statically - there is no device in that model to ask. - Fragmented queries are built in, with a consistency check. A continuation carries the generation it started from, and if the answer changed underneath it is refused with ESTALE, reporting the expected and the current generation instead of reassembling a torn reply. - Attributes are 8-byte aligned. CTLV_ALIGNTO is 8, so a 64-bit payload is naturally aligned and there is no per-family padding to remember - netlink's 4-byte alignment is why nla_put_64bit() needs an explicit NOP pad attribute. - Cheaper round trip. A one-attribute query measured 2.6x cheaper than a genetlink one in the same guest - a debug kernel. - Async operations using io_uring are planned as a follow-up extension. The framework owns validation, schema resolution, blob acquisition, reply serialization and the event queues. All getters and putters are generated helpers. A family implements semantics only, and the aim is to make that hard to get wrong. Would this make sense to use for you? [..]