Is your feature request related to a problem? Please describe.
DAQIRI configuration can parse successfully yet still fail common semantic validation during initialization. Initialization is not a suitable portable validation mechanism because it may allocate packet memory, initialize accelerators or networking engines, or touch a NIC. This prevents checked-in and generated configurations from being authoritatively validated on hardware-free development and checking paths.
Describe the solution you'd like
Provide an installed daqiri_config_validate C++ tool that accepts one or more configuration files and validates them without allocating packet memory, initializing CUDA, DPDK, or RDMA, or touching a NIC. The tool should use the production YAML parser and the same hardware-independent common semantic checks as daqiri_init(), so the runtime and standalone validator share one implementation. It should support both checked-in configurations and configurations produced by tooling.
This is foundation work for #302 and PR #307, which will use the validator to check generated benchmark configurations.
Describe alternatives you've considered
A separate JSON Schema was considered and rejected. It would duplicate the C++ configuration language—including its fields, types, ranges, and semantic relationships—and could drift from the parser and runtime behavior it is intended to describe. Using full initialization as validation was also rejected because initialization is not hardware-free and may allocate memory or access devices.
Additional context
The validator should report parsing and common semantic failures before engine initialization, including invalid scalar types, malformed endpoints, missing memory-region references, unknown flow queue targets, and frames that become oversized after configured transforms. It should be built and installed independently of benchmark examples.
Is your feature request related to a problem? Please describe.
DAQIRI configuration can parse successfully yet still fail common semantic validation during initialization. Initialization is not a suitable portable validation mechanism because it may allocate packet memory, initialize accelerators or networking engines, or touch a NIC. This prevents checked-in and generated configurations from being authoritatively validated on hardware-free development and checking paths.
Describe the solution you'd like
Provide an installed
daqiri_config_validateC++ tool that accepts one or more configuration files and validates them without allocating packet memory, initializing CUDA, DPDK, or RDMA, or touching a NIC. The tool should use the production YAML parser and the same hardware-independent common semantic checks asdaqiri_init(), so the runtime and standalone validator share one implementation. It should support both checked-in configurations and configurations produced by tooling.This is foundation work for #302 and PR #307, which will use the validator to check generated benchmark configurations.
Describe alternatives you've considered
A separate JSON Schema was considered and rejected. It would duplicate the C++ configuration language—including its fields, types, ranges, and semantic relationships—and could drift from the parser and runtime behavior it is intended to describe. Using full initialization as validation was also rejected because initialization is not hardware-free and may allocate memory or access devices.
Additional context
The validator should report parsing and common semantic failures before engine initialization, including invalid scalar types, malformed endpoints, missing memory-region references, unknown flow queue targets, and frames that become oversized after configured transforms. It should be built and installed independently of benchmark examples.