nvidia-holoscan / holoscan-sdk

The AI sensor processing SDK for low latency streaming workflows
Apache License 2.0
114 stars 31 forks source link

Dynamic configuration approach #36

Open JohnMoon-VTS opened 9 hours ago

JohnMoon-VTS commented 9 hours ago

Does Holoscan have a way to dynamically update state in an operator based on some external command?

For example, my team is developing a Holoscan application with the following layout (PR here):

┌───────────┐    ┌─────┐    ┌─────┐    ┌─────────────┐    ┌──────────┐ VRT
│ File Read ├───►│ FFT ├───►│ PSD ├───►│PSD Averaging├───►│Packetizer├─────►
├───────────┤    └─────┘    └─────┘    └─────────────┘    └──────────┘
│Raw IQ Data│
└───────────┘

Now, say we wanted to present an external interface (maybe gRPC) to modify some variables (such as file sample rate or FFT size). My initial thought is to do something like this:


┌───────────┐    ┌─────┐    ┌─────┐    ┌─────────────┐    ┌──────────┐ VRT  
│ File Read ├───►│ FFT ├───►│ PSD ├───►│PSD Averaging├───►│Packetizer├─────►
├───────────◄──┐ └──▲──┘    └─────┘    └─────────────┘    └──────────┘      
│Raw IQ Data│  │    │                                                       
└───────────┘  │    │                                                       
               │    │                                                       
               │    │   ┌─────────────┐                                     
               └────┴───┼ gRPC Server │                                     
                        └─────────────┘                                     

So, the gRPC server would field requests from outside of Holoscan and then go twiddle values in the relevant operators.

In GNU Radio, this sort of approach would be supported with Message Passing, but it seems like in Holoscan this would need to be done with Ports. Is there any concept of message passing in Holoscan (i.e. trigger a callback when I get some message in)? It seems like adding a "configuration" port and checking for new config in every compute() run isn't the right approach.

JohnMoon-VTS commented 7 hours ago

Another thought: I could start the gRPC server as a background thread at the application level and pass it handles to the different operators. Then, it could just modify the config values directly instead of needing a messaging interface. I'm not sure how this would work on a multi-host configuration though.