mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
	"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,
	dri-devel <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v2 7/8] gpu: nova-core: add NVKV typed decoding
Date: Mon, 14 Sep 2026 15:55:14 +0900	[thread overview]
Message-ID: <DLEUCB80B7ZP.BW7O43IISMQR@nvidia.com> (raw)
In-Reply-To: <DLEQBIQ50C39.23F0YZK9D7VUD@nvidia.com>

On Mon Sep 14, 2026 at 12:46 PM JST, Alexandre Courbot wrote:
> On Thu Aug 27, 2026 at 11:12 PM JST, Eliot Courtney wrote:
>> Similar to the typed encoding layer, add some decoding type machinery.
>> Add a simple macro `nvkv_decode!` which implements `Schema` for a struct
>> by composing visit calls to each member. Add some common `Schema` kinds,
>> such as `Array` which collects an array value into a fixed maximum size
>> array, and `Required` which fails a decode if the value is not sent.
>>
>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>> ---
>>  drivers/gpu/nova-core/gsp/nvkv.rs        |  12 +-
>>  drivers/gpu/nova-core/gsp/nvkv/decode.rs | 480 ++++++++++++++++++++++++++++++-
>>  2 files changed, 488 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/gsp/nvkv.rs b/drivers/gpu/nova-core/gsp/nvkv.rs
>> index 10dcbb9e602c..7d58ca91cbc3 100644
>> --- a/drivers/gpu/nova-core/gsp/nvkv.rs
>> +++ b/drivers/gpu/nova-core/gsp/nvkv.rs
>> @@ -9,7 +9,7 @@
>>  //! function calls will map to some struct - for example, f(GPU_NAME_STRING_KEY, 0, b"some gpu")
>>  //! naturally maps to storing a &str with the GPU name.
>>  
>> -#![expect(unused_imports)]
>> +#![cfg_attr(not(CONFIG_KUNIT), expect(unused_imports))]
>
> I am getting a build error on this patch:
>
> error: unused import: `nvkv_encode`
>   --> ../drivers/gpu/nova-core/gsp/nvkv/encode.rs:65:16
>    |
> 65 | pub(crate) use nvkv_encode;
>    |                ^^^^^^^^^^^
>    |
>    = note: `-D unused-imports` implied by `-D warnings`
>    = help: to override `-D warnings` add `#[allow(unused_imports)]`
>
> error: unused import: `nvkv_decode`
>    --> ../drivers/gpu/nova-core/gsp/nvkv/decode.rs:104:16
>     |
> 104 | pub(crate) use nvkv_decode;
>     |                ^^^^^^^^^^^
>
> error: aborting due to 2 previous errors

Thanks for catching this. This builds on 1.85.0 without issue, but I
checked on 1.98.1 and it fails to build. I'll add building with stable
to my checklist.

>
>>  #![cfg_attr(not(CONFIG_KUNIT), expect(unused_macros))]
>>  
>>  use core::marker::PhantomData;
>> @@ -21,7 +21,8 @@
>>  use kernel::{
>>      alloc::{
>>          allocator::KVmalloc,
>> -        Allocator, //
>> +        Allocator,
>> +        ArrayVec, //
>>      },
>>      bitfield,
>>      num::Bounded,
>> @@ -139,6 +140,13 @@ fn default() -> Self {
>>      }
>>  }
>>  
>> +/// A schema field for an array value under the NVKV key `KEY_ID`.
>> +#[derive(Default)]
>> +#[repr(transparent)]
>> +pub(crate) struct Array<T: Default + Copy, const N: usize, const KEY_ID: KeyId> {
>> +    vec: ArrayVec<T, N>,
>> +}
>
> Why is this not defined under `decoder` if it is only used there?

This will be used soon. For example [1] uses it.

[1]: https://lore.kernel.org/all/20260905081116.106613-8-zhiw@nvidia.com/

>
>> +
>>  bitfield! {
>>      /// The op word that starts each NVKV operation.
>>      struct Op(u64) {
>> diff --git a/drivers/gpu/nova-core/gsp/nvkv/decode.rs b/drivers/gpu/nova-core/gsp/nvkv/decode.rs
>> index ceb97e73e100..7f5310857764 100644
>> --- a/drivers/gpu/nova-core/gsp/nvkv/decode.rs
>> +++ b/drivers/gpu/nova-core/gsp/nvkv/decode.rs
>> @@ -3,16 +3,356 @@
>>  
>>  #![cfg_attr(not(CONFIG_KUNIT), expect(dead_code))]
>>  
>> -use kernel::prelude::*;
>> +use core::convert::Infallible;
>> +use core::marker::PhantomData;
>> +
>> +use kernel::{
>> +    alloc::ArrayVec,
>> +    prelude::*, //
>> +};
>> +use pin_init::init_array_from_fn;
>>  
>>  use crate::gsp::nvkv::{
>> +    Array,
>>      Index,
>> +    Key,
>>      KeyId,
>>      Op,
>>      Opcode, //
>>  };
>>  use crate::num;
>>  
>> +/// Defines a schema struct together with its [`Schema`] implementation that decodes into `$target`.
>> +///
>> +/// Each member of the struct should implement `Schema`. For every (key, index, value) triple
>> +/// decoded from the NVKV stream, the generated parent `Schema` implementation will call each member
>> +/// in declaration order with that triple. If a member consumes that triple, it will stop there.
>> +/// Otherwise it will keep going until all members are tried.
>> +///
>> +/// The schema struct holds the state required by the schema implementation to do the decode. It's
>> +/// recommended to use one of the existing Schema kinds (`Required`, `Accumulated`, `Key`, `Array`,
>> +/// `Indexed`) for each member.
>> +///
>> +/// # Examples
>> +///
>> +/// ```
>> +/// nvkv_decode! {
>> +///     struct RequestSchema => Request {
>> +///         id: Required<u32, 0x0001>,
>> +///         name: Array<u8, 64, 0x0002>,
>> +///     }
>> +/// }
>> +/// ```
>> +macro_rules! nvkv_decode {
>> +    (
>> +        $(#[$attr:meta])*
>> +        $vis:vis struct $name:ident => $target:ident {
>> +            $(
>> +                $(#[$field_attr:meta])*
>> +                $field_vis:vis $field:ident : $ty:ty
>> +            ),* $(,)?
>> +        }
>> +    ) => {
>> +        $(#[$attr])*
>> +        $vis struct $name {
>> +            $(
>> +                $(#[$field_attr])*
>> +                $field_vis $field: $ty,
>> +            )*
>> +        }
>> +
>> +        impl $crate::gsp::nvkv::Schema for $name {
>> +            type Target = $target;
>> +
>> +            fn init() -> impl ::kernel::prelude::Init<Self> {
>> +                ::pin_init::init!(Self {
>> +                    $( $field <- <$ty as $crate::gsp::nvkv::Schema>::init(), )*
>> +                })
>> +            }
>> +
>> +            fn visit(
>> +                &mut self,
>> +                key: $crate::gsp::nvkv::KeyId,
>> +                index: $crate::gsp::nvkv::Index,
>> +                value: $crate::gsp::nvkv::DecoderValue<'_>,
>> +            ) -> ::kernel::error::Result<bool> {
>> +                Ok(false
>> +                    $( || $crate::gsp::nvkv::Schema::visit(&mut self.$field, key, index, value)? )*)
>
> Mmm looks like this is going to be `O(n)` with `n` being the number of
> fields?
>
> This is ok for a first implementation but eventually I hope we can
> switch to a more efficient dispatch.

I thought quite a bit about this while writing this code, since we need
the escape hatch to imperative decode (custom Schema impl basically). To
be able to get it down to a match on the key, we need to know ahead of
time which keys a Schema will consume. That duplicates the info from the
visit() implementation.

I thought up a few methods but it's unclear to me which one is best, so
I just left it for now. Please LMK if you think this is urgent, I can
try in a follow up to improve this. Here are my ideas (when I say O(1)
lookup I mean modulo how the compiler decides to do it with the set of
key IDs it gets):

1. current code - just visit()
pros: key source of truth not duplicates
cons: O(field) visit as you say

2. Associated const KEY_ID: Option<KeyId> - None if a Schema accepts multiple keys.
You can match on each associated const in the macro.
pros: O(1) if the current key goes to a field with KEY_ID = Some(...)
cons: O(#fields accepting multiple keys) if current key is one of them

3. fn accepts() -> bool
You can match on `if F::accepts(key)` for each field. We could potentially make
this const with Gary's const traits polyfill.
pros: O(1) if you write an inline-able+optimizable implementation.

4. Associated const KEYS table; use tricks to concat tables
pros: O(1) lookup 
cons: actually MSRV can't get this to optimize down to O(1) 
  if you use slice::contains(), but stable can.

I don't like #2. With the current #1 we can decide later how to optimize.
#3 and #4 feel mostly equal to me, maybe #3 is slightly better.

>
>> +            }
>> +
>> +            #[inline(always)]
>
> In this patch as well these should probably be just `#[inline]`.

Done.

[...]
>> +/// Expects objects specified sequentially with index starting from zero.
>> +pub(crate) struct Accumulated<S: Schema> {
>> +    current_index: Index,
>> +    current: S,
>> +    current_started: bool,
>> +    next: S,
>> +    accumulated: KVVec<S::Target>,
>> +}
>> +
>> +impl<S: Schema + Default> Accumulated<S> {
>> +    /// Creates an empty accumulator.
>> +    pub(crate) fn new() -> Self {
>> +        Self {
>> +            current_index: Index::new::<0>(),
>> +            current: S::default(),
>> +            current_started: false,
>> +            next: S::default(),
>> +            accumulated: KVVec::new(),
>
> Do we want to call `assert_schema_size_reasonable` somewhere here as
> well? Also, should this be a `Default` implementation?

Think we can just remove the ability to construct this without using
init(). Then callers can use stack_pin_init! if they really want it on
the stack.

>
>> +        }
>> +    }
>> +
>> +    fn take_vec(&mut self) -> Result<KVVec<S::Target>> {
>> +        if self.current_started {
>> +            self.accumulated
>> +                .try_push_init(self.current.finish(), GFP_KERNEL)?;
>> +            self.current_started = false;
>> +        }
>> +        self.current_index = Index::new::<0>();
>> +        Ok(core::mem::take(&mut self.accumulated))
>> +    }
>
> This seems to be only called by `finish`, let's inline it there?

Done.

>
>> +}
>> +
>> +impl<S: Schema + Default> Schema for Accumulated<S> {
>
> If this ok that this doesn't provide an `init` implementation? Because
> the default one returns a value on the stack, which IIUC can grow rather
> consequently for an `Accumulated`?

Yeah. So it happens that the stack copies are elided in this particular
case. But I think it's better anyway to do it as you suggest.

>
>> +    type Target = KVVec<S::Target>;
>> +
>> +    fn visit<'a>(&mut self, key: KeyId, index: Index, value: DecoderValue<'a>) -> Result<bool> {
>> +        if index != self.current_index {
>> +            if !self.next.visit(key, Index::new::<0>(), value)? {
>> +                // Unrelated key to us.
>> +                return Ok(false);
>> +            }
>> +
>> +            // Require that objects at index k have all their keys sent before the k + 1 th object
>> +            // can be completed. Require that objects are sent contiguously in order from index 0.
>> +            if !self.current_started || index != self.current_index + 1 {
>> +                return Err(EINVAL);
>> +            }
>> +
>> +            // The current value must be finished. Push it and swap in `next`.
>> +            self.accumulated
>> +                .try_push_init(self.current.finish(), GFP_KERNEL)?;
>> +            core::mem::swap(&mut self.current, &mut self.next);
>> +            self.current_started = true;
>> +            self.current_index = index;
>> +            Ok(true)
>
> I don't quite understand how this method works, notably how
> `current_index` evolves. This might require more documentation on
> `Accumulated` itself.

I added some documentation about how it works. But this is just an
implementation of a finite state machine which tracks the completion of
each child Schema based on the index advancing. It needs some
bookkeeping to handle edge cases like you didn't receive anything / you
got to the end (`current_started`).

>
>> +        } else {
>> +            let consumed = self.current.visit(key, Index::new::<0>(), value)?;
>> +            self.current_started |= consumed;
>> +            Ok(consumed)
>> +        }
>> +    }
>> +
>> +    #[inline(always)]
>> +    fn finish(&mut self) -> impl Init<Self::Target, Error> + '_ {
>> +        self.take_vec()
>> +    }
>> +}
>> +
>> +impl<S: Schema + Default> Default for Accumulated<S> {
>> +    fn default() -> Self {
>> +        Self::new()
>> +    }
>> +}
>> +
>> +/// A schema field that scatters indexed values into an array of `N` slots.
>> +#[repr(transparent)]
>> +pub(crate) struct Indexed<T, const N: usize, const KEY_ID: KeyId, As = T>([T; N], PhantomData<As>);
>
> Can we elaborate a bit on what `As` is supposed to be? Not only on this
> site, but generally speaking. I have a hard time coming with a
> consistent definition, so a comment would help the reader forge their
> understanding.

It's documented on `Key` but not here, let me add a link to it.

>
>> +
>> +/// Copies `elems`, converted to `T`, into `slots` at `start`.
>> +///
>> +/// Fails with `EINVAL` if the window does not fit in `slots`.
>> +fn scatter_window<T: From<As>, As: Copy>(slots: &mut [T], start: usize, elems: &[As]) -> Result {
>> +    let end = start.checked_add(elems.len()).ok_or(EINVAL)?;
>> +    // Reject indices outside of the declared array size.
>> +    let dst = slots.get_mut(start..end).ok_or(EINVAL)?;
>> +    for (d, &e) in dst.iter_mut().zip(elems) {
>> +        *d = T::from(e);
>> +    }
>> +    Ok(())
>> +}
>> +
>> +impl<T, const N: usize, const KEY_ID: KeyId, As> Schema for Indexed<T, N, KEY_ID, As>
>
> Same question as `Accumulated` about the lack of an `init` method -
> maybe we can use `init_array_from_fn` to avoid a stack copy.
>
> Actually that makes me think that maybe the default `Schema::init`
> implementation is not such good an idea, because it makes us overlook
> types where we should override it.

Yeah agreed on all points.

>
>> +where
>> +    T: From<As> + Default,
>> +    As: Copy + for<'a> TryFrom<DecoderValue<'a>, Error = Error>,
>> +    for<'a> &'a [As]: TryFrom<DecoderValue<'a>, Error = Error>,
>> +{
>> +    type Target = [T; N];
>> +
>> +    fn visit<'a>(&mut self, key: KeyId, index: Index, value: DecoderValue<'a>) -> Result<bool> {
>> +        if key != KEY_ID {
>> +            return Ok(false);
>> +        }
>> +        let start = index.cast::<usize>().get();
>> +        // Accept both scalar vs scattered array setting for flexibility.
>> +        match <&[As]>::try_from(value) {
>> +            Ok(elems) => scatter_window(&mut self.0, start, elems)?,
>> +            Err(_) => scatter_window(&mut self.0, start, &[As::try_from(value)?])?,
>> +        }
>> +        Ok(true)
>> +    }
>> +
>> +    #[inline(always)]
>> +    fn finish(&mut self) -> impl Init<Self::Target, Error> + '_ {
>> +        init_array_from_fn(|i| Ok::<_, Error>(core::mem::take(&mut self.0[i])))
>> +    }
>> +}
>> +
>> +impl<T: Default + Copy, const N: usize, const KEY_ID: KeyId, As> Default
>> +    for Indexed<T, N, KEY_ID, As>
>> +{
>> +    fn default() -> Self {
>> +        assert_schema_size_reasonable::<Self>();
>> +        Self([T::default(); N], PhantomData)
>> +    }
>
> Mmm that could be a pretty large object. Where are these `default`
> methods called? Do we want to leverage `init` instead?

Yerp

>
> <...>
>> +    // Tests that a schema too large for the stack decodes on the heap.
>> +    #[test]
>> +    fn decode_large_schema_on_heap() -> Result {
>> +        const BLOB_KEY: KeyId = 0x1400;
>> +        const BLOB_VALUE: &[u8] = &[0xab; 100];
>> +
>> +        nvkv_decode! {
>> +            struct BigSchema => BigDecodeable {
>> +                blob: Array<u8, 2048, { BLOB_KEY }>,
>> +            }
>> +        }
>> +
>> +        struct BigDecodeable {
>> +            blob: ArrayVec<u8, 2048>,
>> +        }
>> +
>> +        let mut encoder = Encoder::new();
>> +        encoder.encode_array8(BLOB_KEY, Index::new::<0>(), BLOB_VALUE)?;
>> +        let serialized = encoder.finish();
>> +
>> +        let mut schema = KBox::init(BigSchema::init(), GFP_KERNEL)?;
>> +        let decoder = Decoder::new(&serialized, UnknownKeyPolicy::Error);
>> +        let decoded = KBox::try_init(decoder.decode(&mut *schema)?, GFP_KERNEL)?;
>> +
>> +        assert_eq!(*decoded.blob, *BLOB_VALUE);
>> +        Ok(())
>> +    }
>
> Same as the encoder, it would be nice to exercise the error paths a bit
> more in the tests.

Will do.


  reply	other threads:[~2026-09-14  6:55 UTC|newest]

Thread overview: 30+ 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:12 ` [PATCH v2 3/8] rust: alloc: add ArrayVec Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 4/8] gpu: nova-core: add NVKV encoder Eliot Courtney
2026-09-07 15:07   ` Alexandre Courbot
2026-09-14  4:44     ` Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 5/8] gpu: nova-core: add NVKV decoder Eliot Courtney
2026-09-09  0:51   ` Alexandre Courbot
2026-09-09  1:13     ` Eliot Courtney
2026-09-09  4:48       ` Alexandre Courbot
2026-09-14  4:45         ` Eliot Courtney
2026-09-10  7:47   ` Alexandre Courbot
2026-09-14  5:45     ` Eliot Courtney
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-09-14  4:46           ` Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 7/8] gpu: nova-core: add NVKV typed decoding Eliot Courtney
2026-09-14  3:46   ` Alexandre Courbot
2026-09-14  6:55     ` Eliot Courtney [this message]
2026-09-14  7:04       ` John Hubbard
2026-09-14  7:16         ` Eliot Courtney
2026-09-14 12:06           ` Alexandre Courbot
2026-08-27 14:12 ` [PATCH v2 8/8] gpu: nova-core: add NVKV GSP_INIT schemas Eliot Courtney
2026-09-14  4:11   ` Alexandre Courbot
2026-09-14  5:42     ` Eliot Courtney
2026-09-14 12:12       ` Alexandre Courbot

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=DLEUCB80B7ZP.BW7O43IISMQR@nvidia.com \
    --to=ecourtney@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --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-bounces@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®