Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TDBSTore: skip data CRC when building RAM table #15514

Merged
merged 1 commit into from
Jun 8, 2024

Conversation

mattgbio
Copy link
Contributor

@mattgbio mattgbio commented May 7, 2024

Summary of changes

Problem: The build_ram_table() function of TDBStore loops over every entry, calculates the checksum and compares them to the stored checksum in the entry header to ensure integrity. For larger TDBStores (e.g. 8 MiB or more) in external single-SPI flash devices this check can take very long, thus rendering it unusable in some cases.

Solution: The suggested solution skips the time consuming CRC of the data. After reading the key and calculating its CRC, it sets next_offset to the beginning of the next entry, thereby skipping the data. While this skips the integrity check, it significantly reduces the initial building of the RAM table.

The data CRC can be enabled or disabled with a compiler flag.

Contribution is provided on behalf of BIOTRONIK.

Impact of changes

Migration actions required

Documentation

None


Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Tests run at our company show full functionality. The RAM table for existing TDBStores with up to 1000 entries is correctly built.


Reviewers


@mbed-ci
Copy link

mbed-ci commented May 15, 2024

Jenkins CI Test : ❌ FAILED

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test

@mergify mergify bot added needs: work and removed needs: CI labels May 15, 2024
@0xc0170
Copy link
Contributor

0xc0170 commented May 21, 2024

Can you add the details to the commit message please? The same info you provided in the description here would be good.

Problem: The build_ram_table() function of TDBStore loops over every entry, calculates the checksum and compares them to the stored checksum in the entry header to ensure integrity. For larger TDBStores (e.g. 8 MiB or more) in external single-SPI flash devices this check can take very long, thus rendering it unusable in some cases.

Solution: The suggested solution skips the time consuming CRC of the data. After reading the key and calculating its CRC, it sets next_offset to the beginning of the next entry, thereby skipping the data. While this skips the integrity check, it significantly reduces the initial building of the RAM table.

The data CRC can be enabled or disabled with a compiler flag.

Contribution is provided on behalf of BIOTRONIK.
@mbed-ci
Copy link

mbed-ci commented May 27, 2024

Jenkins CI Test : ❌ FAILED

Build Number: 2 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM ✔️
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-ARM ✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_greentea-test

@mergify mergify bot added needs: work and removed needs: CI labels May 27, 2024
@0xc0170 0xc0170 added ready for merge release-type: patch Indentifies a PR as containing just a patch and removed needs: work labels Jun 8, 2024
@0xc0170 0xc0170 merged commit 5cb118b into ARMmbed:master Jun 8, 2024
18 of 20 checks passed
@mergify mergify bot removed the ready for merge label Jun 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-type: patch Indentifies a PR as containing just a patch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants