Hi Marc, > See the code that the "-d" command line options activates :) Ah, duh, sorry! I think I need to work on my google-fu; I hadn't come across the SO_RXQ_OVFL option. That looks like exactly what I was hoping for. > We currently don't have an API for stopping/aborting CAN frames, the > only thing you can do is ifdown/ifup the interface. Unfortunate, but it's great to get a firm answer on that. I'll work around it for now. Thank you! David On Fri, Aug 12, 2022 at 5:37 AM Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > > On 11.08.2022 13:17:47, David Boles wrote: > > Thank you Marc and Tom for your suggestions! I have a few follow-ups: > > I'm missing Tom's mail, seems it didn't make it to the mailing list. > > > # Question 1: Silently losing received frames if the socket isn't read > > from frequently enough > > > > > See candump's "-d" command line option. > > > > 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. > > > Yep, that's what I'm currently doing. It's probably an acceptable > > solution though not ideal; I'd like to be able to detect this > > happening and fail noisily. > > > > # Question 2: Behavior of one-shot and presume-ack > > > > It sounds like one-shot doesn't retry in the event of other problems > > (like losing arbitration) so that isn't what I want. It sounds like > > presume-ack is what I wanted but is only supported by very few > > devices, so I probably don't want to use it either. > > > > # New: Question 4 > > > > I think the right course of action is to detect (either via > > looped-back frames or maybe error frames, or something else) that my > > transceiver is the only one on the bus and to stop sending messages > > temporarily. I'd like to avoid sending excessively stale frames (e.g. > > if a new transceiver joins the bus five minutes later, it shouldn't > > receive a five minute old frame from me) and from my testing with > > PCAN-USB dongles they seem to try resending a frame endlessly. > > We currently don't have an API for stopping/aborting CAN frames, the > only thing you can do is ifdown/ifup the interface. > > > I'd > > also like to avoid missing receiving frames transmitted by any new > > transceivers on the bus. Is there any universal/reliable API for > > clearing all transmit buffers for an interface, down to the device > > itself, without affecting its ability to receive frames? > > No - currently there's only the down/up method. > > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
