Am 23.08.2011 14:22, schrieb Oliver Hartkopp: >> 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 ... > Hi Oliver,
Thanks for this very promising idea! I wanted to try it, but I have at least one big problem with it: even with my test-kernel 2.6.35.7 I can't use it, because I have glibc-2.6 and recvmmsg is supported since glibc-2.14. A rebuild of glibc is out of question (way too much effort). But it is Friday and I have some other good news! (see my other email) :) Best regards, René >> >> 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 _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
