feat: upgrade of deserialization of RVF.

[ShadowCurse]

• Rewrote deserialization method for RegisterValueFilter.
• Improved performance by ~75%.
• Added ability to use _ in string representation.

running: cargo bench --bench cpu_templates

deserialize_cpu_template
                        time:   [5.5389 µs 5.5402 µs 5.5419 µs]
                        change: [-77.543% -77.536% -77.530%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 11 outliers among 200 measurements (5.50%)
  2 (1.00%) low mild
  4 (2.00%) high mild
  5 (2.50%) high severe

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following
Developer Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• If a specific issue led to this PR, this PR closes the issue.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• API changes follow the Runbook for Firecracker API changes.
• User-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.
• New TODOs link to an issue.
• Commits meet contribution quality standards.

---

• This functionality cannot be added in rust-vmm.

[zulinx86]

Improved performance by ~65%.

Great news! Should we update baseline values as well?
https://github.com/firecracker-microvm/firecracker/blob/main/tests/integration_tests/performance/test_cpu_template_benchmark.py

[ShadowCurse]

@zulinx86 Because perf tests pass I assume the delta is big enough for this improvement. I don't really think changing baselines here is necessary.

[zulinx86]

@zulinx86 Because perf tests pass I assume the delta is big enough for this improvement. I don't really think changing baselines here is necessary.

Hmm, 65% looks huge enough to me.
But this issue seems to be caused by the fact that the benchmark measure it in milliseconds granularity.
https://github.com/firecracker-microvm/firecracker/blob/main/tests/integration_tests/performance/test_cpu_template_benchmark.py#L25-L38

For future reference, I'd appreciate if you could post the benchmark result before and after the change here.

[roypat]

Mh, is this on the hot path? I'm not very familiar with y'all's work the past few months, but I thought that the json deserialization wasn't supposed to be on the hot path and instead some optimized binary forward was used? :o

[zulinx86]

Mh, is this on the hot path? I'm not very familiar with y'all's work the past few months, but I thought that the json deserialization wasn't supposed to be on the hot path and instead some optimized binary forward was used? :o

I don't have full context behind that, but the baseline values are ~45 us on x86 and ~7.5us on aarch64.
https://github.com/firecracker-microvm/firecracker/blob/main/tests/integration_tests/performance/test_cpu_template_benchmark.py#L25-L38

Test templates are here:

• https://github.com/firecracker-microvm/firecracker/blob/main/src/vmm/src/cpu_config/x86_64/test_utils.rs
• https://github.com/firecracker-microvm/firecracker/blob/main/src/vmm/src/cpu_config/aarch64/test_utils.rs

IIUC, we don't support binary compiled CPU template in firecracker v1.4. If users need more performance, we can support binary ones in successive versions.

@mattschlebusch Do you have more context about this?

[ShadowCurse]

Mh, is this on the hot path? I'm not very familiar with y'all's work the past few months, but I thought that the json deserialization wasn't supposed to be on the hot path and instead some optimized binary forward was used? :o

So this whole PR was created, because I thought adding _ as a separator would be nice in our trinary format.
The refactoring just came naturally. Why wouldn't I optimize code that I touch?