Re: [PATCH v2 2/4] gpu: nova-core: gsp: add sync and async command queue API to `Cmdq`

[John Hubbard <jhubbard@nvidia.com>]

On 3/2/26 4:28 AM, Danilo Krummrich wrote:
> On Sat Feb 28, 2026 at 7:11 AM CET, John Hubbard wrote:
>> The sync/async naming that GSP RM uses is a little bit "off". I
>> spent some time discussing it with them, and the problem is that
>> sync/async is a concept that is somewhat independent of whether
>> a reply is expected. Usually, sync means a blocking wait for a
>> response, which is not necessarily required in all case with
>> GSP RM calls.
>>
>> The naming would be better here if it reflected simply that
>> a response is expected, or not. I don't have great names for
>> that, but "fire and forget" works well for what we have so
>> far called "async". So we could do create a convention in which
>> no annotation means that the API has a response that will come
>> back, and some abbreviated for of "fire and forget" or "one way"
>> added to the function name would mean that no response is
>> expected.
> 
> I think the relevant information for the caller is whether the call is blocking
> or non-blocking; i.e. do we have cases where we want to block, but discard the
> reply, or expect a reply but don't want to wait for it?
> 
> So, unless there is additional complexity I'm not aware of, I feel like
> send_command() and send_command_no_wait() should be sufficient.

That's my favorite so far. It's unencumbered by any assumptions about
behavior, and unambiguous about what it does, and shorter names too.

> 
> (Maybe send_command_wait() if we want to be a bit more explicit.)
> 
> As for the specific commands, we could have traits to control whether blocking
> or non-blocking submissions are allowed for them in the first place, i.e. this
> gives us some control about whether a reply is allowed to be discarded through a
> _no_wait() submission etc.

thanks,
-- 
John Hubbard