Conversation
|
|
||
| ## Alternatives Considered | ||
|
|
||
| - FPGA Agent as part of a current agent. This would result in fewer separate Agent softwares running on DZDs, but would bundle unrelated functions together. For example, transit DZDs do not have FPGAs associated with them, and do not need the FPGA Agent functionality. |
There was a problem hiding this comment.
- FPGA Agent as part of a current agent. This would result in fewer separate Agent softwares running on DZDs, but would bundle unrelated functions together.
We already have unrelated functions together in agents. The telemetry agent was meant for measuring link latency only. Now it's also responsible for polling state off the DZD. Since this new agent is responsible for FGPA configuration/monitoring, at a minimum, we should think seriously about adding this to the existing config agent.
For example, transit DZDs do not have FPGAs associated with them, and do not need the FPGA Agent functionality.
The type of DZD (i.e. hybrid, transit, etc) is marked onchain. It seems trivial to be able to derive the locally running type at runtime and either start a thread for FPGA management or not.
There was a problem hiding this comment.
I'm open to the concept of folding it into the existing config agent, in my initial conversations with @armcconnell, we'd talked about doing it as a separate agent.
If we combine, we'll need to be careful to make sure programming and reads/writes to the FPGA get spun off so that they're non-blocking to unrelated config code. The FPGA portion can only be doing one thing at a time via the cable drivers, so it being self-blocking wouldn't be an issue, but some steps take a while.
| #### Control Behavior | ||
| The FPGA Agent will also provide control configuration to the FPGAs. This may include things like providing IP addresses for Validators subscribed to packet filtering, along with configuration options requested by those validators. | ||
|
|
||
| Control data will be sourced from the DZ ledger via the controller, polled at the interval provided by `--sleep-interval-in-seconds`. When users request a connection in edge filtering mode, they will also provide all required configuration for the FPGA, including what type of filtering they're opting into. |
There was a problem hiding this comment.
Why not talk directly to the side chain RPC instead of to the controller?
There was a problem hiding this comment.
Thought that was how the current agent worked- was trying to be consistent.
2 participants
Summary of Changes
Testing Verification
N/A