Hi all,
On 03.03.23 18:26, Michal Sojka wrote:
I tried the exact same commit. When the system running the test is
mostly idle, I have to wait many minutes to loose the packet. But when I
run the test simultaneously with Linux kernel compilation on all CPUs
(make -j$(nproc)), the packet is lost almost immediately.
I'm still testing with:
- receiver: ./isotp-poll-test -s 321 -d 123 -i -a -b -q
- sender: ./isotp-poll-test -s 123 -d 321 -o -w -b
I've performed some more tests.
The poll V2 patch seems to do the job!
The problem with the kernel compilation is caused by scheduling in the
way that the receiving process is not fast enough to grab the PDUs from
the socket until the socket receive buffer gets an overflow.
To prove this idea I added the possibility to detect dropped PDUs in the
recvmsg() syscall of isotp.c, see:
https://lore.kernel.org/linux-can/20230330170248.62342-1-socketcan@xxxxxxxxxxxx/T/#u
Additionally the isotp-pool-test was extended to retrieve the
SOCK_RXQ_OVFL information.
And then "compiling the kernel" the drop counter triggered every time.
So I added the option the increase the sockets receive buffer and with
./isotp-poll-test -s 321 -d 123 -i -a -b -r 20000000
(as root)
the drops were gone - even when compiling the kernel.
See https://github.com/hartkopp/isotp-poll-test for the extensions of
isotp-pool-test.c
@Michal/Jakub: Feel free to try this out.
Thanks & best regards,
Oliver
