Ok, i must admit this is a bit like fishing in murky waters but i do not
know which impact the recvmsg() syscall hass in this game.
When integrating the support for dropcounts i moved the receiption of
CAN frames from recvfrom() to recvmsg() to get all the information
including timestamps and dropcounts with one syscall:
http://svn.berlios.de/wsvn/socketcan?op=comp&compare[]=/trunk/can-utils/candump.c@1110&compare[]=/trunk/can-utils/candump.c@1111
This has an increased effort in setting and parsing cmsg structures.
Maybe you can try to modify the rev1110 to your needs (with the CAN
frame array) or use the very simple socketcan/test/tst-raw.c source as a
basis that only uses read() without any multi-socket- nor select()-support.
Another idea could be to use recvmmsg()
See http://kernelnewbies.org/Linux_2_6_33 Chapter 1.4
http://vger.kernel.org/netconf2009_slides/recvmmsg.pdf
I did not test this so far ...
This would be interesting to see if we really can save remarkable
amounts of CPU time without having the full-featured candump mechanisms.
Best regards & thanks for the interesting CPU/MEM tradeoff problem ;-)
Oliver
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users
