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/1/26 6:22 PM, Eliot Courtney wrote:
> On Sat Feb 28, 2026 at 3:11 PM JST, John Hubbard wrote:
>> On 2/26/26 7:50 AM, Eliot Courtney wrote:
>>> Add sync and async command queue API and the type infrastructure to know
>>> what reply is expected from each `CommandToGsp`.
>>>
>>> Use a marker type `NoReply` which does not implement `MessageFromGsp` to
>>> mark async commands which don't expect a response.
>>>
>> ...
> Hi John,
> 
> I totally agree and was hoping that someone would have a good suggestion
> for this. I discussed this exact thing with Alex before posting this
> too. So if you have any naming suggestions would love to hear them.
> 
> As you say, sync and async are orthogonal to reply vs no reply. I think
> we have several ideas here actually:
> - blocking vs non-blocking
> - reply vs no-reply
> - wait for reply vs don't wait for reply (practically equivalent to
>    blocking vs non-blocking here, but conceptually the send could also be
>    blocking vs non-blocking)
> 
> We should also be careful with conflating waiting for the reply vs not
> having a reply. So `send_without_waiting_for_reply` is definitely
> confusing to me, because there may be a reply that we just don't wait
> for.
> 
> Some ideas:
> - send_command_with_reply + send_command_without_reply
>    - Maybe non-obvious that this blocks for send_command_with_reply.
> - send_and_wait_for_reply + send_no_reply
>    - More obvious that it blocks and gets the reply.
>    - Should be obvious from context that you are sending a command
>      anyway.
> 
> Personally I think it's nice to keep a convention of keeping it
> mostly obvious which functions block/wait. (e.g. we already have
> wait_for_msg in cmdq.rs).
> 
> For lack of a better idea  i suggest send_and_wait_for_reply +
> send_no_reply for now.

That sounds great, I'd love to start with that. Simple and clear.

One thing: "send no reply" sounds a lot like "do not send a reply". :)
So maybe:

     send_and_wait_for_reply()
     send_without_waiting_for_reply()

? Or something along those lines? It's really verbose I know...

thanks,
-- 
John Hubbard