Hi Oliver, > Can you probably tell me more about your use-case? > The last time I had your described issues, I was routing CAN frames via > userspace - which finally led to the implementation of the can-gw module ;-) Yep! Excellent guess :D For a few different reasons, that's basically what I'm hoping to do. If it doesn't work out, I'll definitely dig into your suggestions. > All these measures seem to be the last solution when nothing else helped. Fortunately I haven't actually had a problem with keeping up with receiving frames, I was just hoping for something a little more robust than "configure a large buffer and assume that your program is keeping up because it has before". SO_RXQ_OVFL sounds like the correct answer for me. Thank you! David On Fri, Aug 12, 2022 at 6:01 AM Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote: > > Hello David, > > On 12.08.22 14:37, Marc Kleine-Budde wrote: > > On 11.08.2022 13:17:47, David Boles wrote: > > >> Unfortunately it seems like this is happening at the layer of > >> individual sockets. Candump was already printing out messages that I > >> was "losing", and adding the -d flag doesn't affect its printout > >> (presumably since from its perspective, they haven't been dropped). > > > > See the code that the "-d" command line options activates :) > > > > | https://github.com/linux-can/can-utils/blob/master/candump.c#L650 > > > > ... and add this to your app. > > > >>> Run your program at a lower NICE value > > > > You can try to receive several CAN frames with recvmmsg(). > > > >> Good idea! > >> > >>> Make the queue as big as you can. > > > > I the socket drops CAN frames, this means there's not enough CPU time > > for your app to receive them all. You should look at your system and > > find out where the CPU time is lost. > > All these measures seem to be the last solution when nothing else helped. > > Can you probably tell me more about your use-case? > > 1. e.g. when you are using the CAN_RAW socket: Do you set CAN filters to > pass only needed content into userspace? > > When you drop 50% of the CAN IDs in userspace you still have to transfer > them from kernelspace to userspace and check if you should drop them. > > 2. when you need to filter for updates in specific content in the CAN > frames data[] section the CAN_BCM socket is your friend. Especially for > cyclic sent CAN messages e.g. in automotive use-cases. > > 3. When you need to forward and/or modify CAN frames between CAN > interfaces there is a special netlink-based in-kernel CAN-Gateway which > can be controlled by the 'cangw' tool. > > The last time I had your described issues, I was routing CAN frames via > userspace - which finally led to the implementation of the can-gw module ;-) > > Best regards, > Oliver > >
