tests: settings: Performance test for settings #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
omkar3141
force-pushed
the
zms_perf_test
branch
2 times, most recently
from
b658c5d
to
8ed2e37
Compare
omkar3141
force-pushed
the
zms_perf_test
branch
from
8ed2e37
to
37ad5e8
Compare
This adds a on target performance test for Settings SS. Using this test performance of the Setting SS + NVS/ZMS backend can be benchmarked. The test repeatedly write 255 settings entries. Each setting entry has a size of 4 bytes, and path length of 16 bytes (excluding the null-terminator). The test has two variants, with and without Bluetooth scan running. This is useful to benchmark performance along with some component of BT subsystem activated. The test could be enhanced in future to include or create combinations of different functionalities running, when agreesive store operations are happening. Signed-off-by: Omkar Kulkarni <[email protected]>
omkar3141
force-pushed
the
zms_perf_test
branch
from
37ad5e8
to
9abe248
Compare
rghaddab
pushed a commit
that referenced
this pull request
Oct 28, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.
==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68
READ of size 2 at 0x000000ad81c2 thread T6
#0 0x5279b2 (/root/zephyr.exe+0x5279b2)
#1 0x4d697d (/root/zephyr.exe+0x4d697d)
zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T2 created by T1 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T1 created by T0 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x52f36c (/root/zephyr.exe+0x52f36c)
zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc)
zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6)
zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b)
zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd)
zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
==5==ABORTING
Signed-off-by: Sungwoo Kim <[email protected]>
rghaddab
pushed a commit
that referenced
this pull request
Nov 6, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.
This causes problems two-fold with checksum calculations:
1. The "config" isn't uninitialized, so, every call returns differnet
values. So, for UDP header checksum would be done and
pkt->chksumdone would be set. But for IPv4 header checksum might be
skipped.
2. Even if we initialize to zero, then network stack gets all zeros
and calculates checksum by itself rendering offload moot.
There is another problem in #1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).
But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.
Upstream PR #: 80882
Signed-off-by: Chaitanya Tata <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a on target performance test for Settings SS. Using this test performance of the Setting SS + NVS/ZMS backend can be benchmarked.
The test repeatedly write 255 settings entries. Each setting entry has a size of 4 bytes, and path length of 16 bytes (excluding the null-terminator).
The test has two variants, with and without Bluetooth scan running. This is useful to benchmark performance along with some component of BT subsystem activated.
The test could be enhanced in future to include or create combinations of different functionalities running, when aggressive store operations are happening.
Results on desk for 54L15 platform: