Overview of the Sample MRL Requirements File
For the demo, you will use a sample requirements file specific to the MRL workload, with predefined values. The sample MRL requirements file is shown below:
"command": "python3 /usr/share/tcc_tools/tools/demo/workloads/bin/mrl_validation_script.py",
In the requirements file, the “workload” fields specify the workload validation script command and arguments. After generating a tuning configuration, the tool will run the workload validation script. This demo uses a sample script specific to the MRL application.
“command” shows the sample script that will be used to validate
MRL latency during the tool flow. The exit code must return 0 if the requirements are met and 1 if the requirements are not met. Any other value means the validation failed to complete, and the tuning process will stop. Any type of program is OK.
argument specifies the device for the MMIO read. The device could be an Intel® Ethernet Controller I225 or an Ethernet controller with embedded Time-Sensitive Networking.
argument specifies the number of iterations to run.
argument specifies the maximum latency requirement in microseconds (us) to be verified. As defined earlier in this scenario, the requirement is 90 microseconds. In the requirements file, this argument is used twice. The first time it is a validation script requirement to detect whether the test passes or fails. The second time is for the data streams optimizer to apply configurations that have a latency less than the value.
argument specifies that the sample will run on processor core 3.
The “requirements” fields specify the data stream requirements that the tool will use to generate the aforementioned tuning configuration.
The compatibility option identifies which features are required to be used with the data streams optimizer, in this case software SRAM is specified. Specifying the compatibility option ensures tuning configurations selected by the data streams optimizer are compatible with specified features. Some tuning configurations enable power management options that are not compatible with software SRAM and RTCM. For this demo, the compatibility option is set to SoftwareSRAM to ensure there will be no compatibility issues if you choose to run this demo and use the cache allocation tools on the same system. Although this setting reduces the number of tuning configurations that the data streams optimizer can use, the remaining configurations are enough to tune the system to meet the demo’s requirements. For details about compatibility between the data streams optimizer and other features, see Compatibility between Data Streams Optimizer and Cache Allocation
The data stream is specified in the form of a producer/consumer pair.
For the core-from-PCIe stream, the “producer” value is always the PCIe device in Bus:Device.Function (BDF) notation with additional Traffic Class (TC) specified. The BDF value varies by PCIe device, and specific BDF for the demo will be inserted later depending on the target device. The “consumer” value is always the processor core in the format CoreNumber.
The “latency_us” and “bytes_per_transfer” fields specify the requirements for the data stream. For the core-from-PCIe stream, latency is defined as the maximum acceptable time needed to read the targeted MMIO addressable region and return the requested data in microseconds. The “bytes_per_transfer” value is defined as the burst size of the buffer that is part of the real-time control loop. In other words, amount of bytes read. For more information about generating requirements for this data stream and others, see Generate Requirements
The “relative_priority” field is not used in this release.