From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Uladzislau Rezki" <urezki@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Onur Özkan" <work@onurozkan.dev>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 4/8] gpu: nova-core: add NVKV encoder
Date: Tue, 08 Sep 2026 00:07:45 +0900 [thread overview]
Message-ID: <DL96FLHTRWOI.1FKOXD8RCXBUP@nvidia.com> (raw)
In-Reply-To: <20260827-b4-nvkv-v2-4-0de9d5c8658c@nvidia.com>
On Thu Aug 27, 2026 at 11:12 PM JST, Eliot Courtney wrote:
<...>
> +/// An encoded NVKV byte stream.
> +///
> +/// # Invariants
> +///
> +/// The byte length is always a multiple of `size_of::<u64>()`.
> +pub(crate) struct EncodedStream(Vec<u8, StreamAllocator>);
> +
> +impl EncodedStream {
> + /// Creates an empty stream.
> + fn new() -> Self {
> + // INVARIANT: An empty stream's byte length is 0, a multiple of `size_of::<u64>()`.
> + Self(Vec::new())
> + }
> +
> + /// Appends a single `u64` to the stream.
> + fn push_u64(&mut self, value: u64) -> Result {
> + // INVARIANT: Appending `size_of::<u64>()` bytes keeps the byte length a multiple of
> + // `size_of::<u64>()`.
> + Ok(self.0.extend_from_slice(&value.to_ne_bytes(), GFP_KERNEL)?)
> + }
> +
> + /// Appends `data` as bytes to the stream, zero-padded to a `u64` boundary.
> + fn extend_with_padding<T: IntoBytes + Immutable + ?Sized>(&mut self, data: &T) -> Result {
> + let bytes = data.as_bytes();
> + let padded = bytes.len().next_multiple_of(size_of::<u64>());
> + // Reserve so that a failed allocation can't leave the invariant violated.
> + self.0.reserve(padded, GFP_KERNEL)?;
> + self.0.extend_from_slice(bytes, GFP_KERNEL)?;
> + // INVARIANT: The padding ensures the total length remains a multiple of
> + // `size_of::<u64>()`.
> + Ok(self.0.extend_with(padded - bytes.len(), 0u8, GFP_KERNEL)?)
> + }
> +}
> +
> +// The Deref to &[u64] relies on this alignment guarantee.
nit: `&[u64]`.
<...>
> +/// Describes the format of the following NVKV operation.
> +#[derive(Debug, Copy, Clone, PartialEq, Eq)]
> +#[repr(u8)]
> +enum Opcode {
> + /// A 32-bit value in the op word.
> + Imm32 = 0,
> + /// 32-bit values for consecutive keys, starting at the op word's key.
> + Seq32 = 1,
> + /// 64-bit values for consecutive keys, starting at the op word's key.
> + Seq64 = 2,
> + /// An array of bytes.
> + Array8 = 3,
> + /// An array of 32-bit elements.
> + Array32 = 4,
> + /// An array of 64-bit elements.
> + Array64 = 5,
> +}
> +
> +// TODO[FPRI]: This is a temporary solution to be replaced with the corresponding derive macros once
> +// they land.
Actually, can't you use the nova-core local `bounded_enum!` macro to
define `OpCode`? This would generate the implementations below automatically.
> +impl TryFrom<Bounded<u64, 4>> for Opcode {
> + type Error = Error;
> +
> + fn try_from(value: Bounded<u64, 4>) -> Result<Self> {
> + match value.get() {
> + 0 => Ok(Self::Imm32),
> + 1 => Ok(Self::Seq32),
> + 2 => Ok(Self::Seq64),
> + 3 => Ok(Self::Array8),
> + 4 => Ok(Self::Array32),
> + 5 => Ok(Self::Array64),
> + _ => Err(EINVAL),
> + }
> + }
> +}
> +
> +impl From<Opcode> for Bounded<u64, 4> {
> + fn from(value: Opcode) -> Self {
> + Bounded::from_expr(value as u64)
> + }
> +}
Sashiko has a point that `from` requires `#[inline(always)]`. Ideally,
we prefer to avoid using `from_expr` when we can, which in this case we
can by doing an exhaustive enumeration. Which is exactly what the
`bounded_enum` does, so leveraging it also solves this issue. :)
> diff --git a/drivers/gpu/nova-core/gsp/nvkv/encode.rs b/drivers/gpu/nova-core/gsp/nvkv/encode.rs
> new file mode 100644
> index 000000000000..6c1a9cbd90e8
> --- /dev/null
> +++ b/drivers/gpu/nova-core/gsp/nvkv/encode.rs
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
> +
> +#![cfg_attr(not(CONFIG_KUNIT), expect(dead_code))]
> +
> +use kernel::prelude::*;
> +
> +use super::{
> + EncodedStream,
> + Index,
> + KeyId,
> + Op,
> + Opcode, //
> +};
> +
> +/// An encoder for an NVKV stream.
> +pub(crate) struct Encoder {
> + stream: EncodedStream,
> +}
> +
> +impl Encoder {
> + /// Creates an empty encoder.
> + pub(crate) fn new() -> Self {
> + Self {
> + stream: EncodedStream::new(),
> + }
> + }
> +
> + /// Returns the encoded data.
> + #[must_use = "encoded stream must be consumed"]
> + pub(crate) fn finish(self) -> EncodedStream {
> + self.stream
> + }
> +
> + #[inline(always)]
Unless not inlining implies a build error (as is the case for
`Bounded::from_expr`), I think the convention is to stick to `#[inline]`
for these.
Same applies for other methods.
next prev parent reply other threads:[~2026-09-07 15:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 14:12 [PATCH v2 0/8] gpu: nova-core: add NVKV codec Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 1/8] rust: alloc: add Vec::try_push_init Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 2/8] rust: alloc: add Vec::push_init Eliot Courtney
2026-08-27 14:30 ` sashiko-bot
2026-08-27 14:12 ` [PATCH v2 3/8] rust: alloc: add ArrayVec Eliot Courtney
2026-08-27 14:33 ` sashiko-bot
2026-08-27 14:12 ` [PATCH v2 4/8] gpu: nova-core: add NVKV encoder Eliot Courtney
2026-08-27 14:35 ` sashiko-bot
2026-09-07 15:07 ` Alexandre Courbot [this message]
2026-08-27 14:12 ` [PATCH v2 5/8] gpu: nova-core: add NVKV decoder Eliot Courtney
2026-08-27 14:36 ` sashiko-bot
2026-09-09 0:51 ` Alexandre Courbot
2026-09-09 1:13 ` Eliot Courtney
2026-09-09 4:48 ` Alexandre Courbot
2026-09-10 7:47 ` Alexandre Courbot
2026-08-27 14:12 ` [PATCH v2 6/8] gpu: nova-core: add NVKV typed encoding Eliot Courtney
2026-09-10 8:10 ` Alexandre Courbot
2026-09-11 5:17 ` Alexandre Courbot
2026-09-11 5:28 ` Eliot Courtney
2026-09-11 11:18 ` Alexandre Courbot
2026-08-27 14:12 ` [PATCH v2 7/8] gpu: nova-core: add NVKV typed decoding Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 8/8] gpu: nova-core: add NVKV GSP_INIT schemas Eliot Courtney
2026-08-27 14:34 ` sashiko-bot
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=DL96FLHTRWOI.1FKOXD8RCXBUP@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=urezki@gmail.com \
--cc=vbabka@kernel.org \
--cc=work@onurozkan.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.