Linux CAN drivers development
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: David Boles <me@davidbol.es>
Cc: Tom Evans <thomasaevans@optusnet.com.au>,
	linux-can@vger.kernel.org, s.grosjean@peak-system.com
Subject: Re: PCAN and SocketCAN Questions
Date: Fri, 12 Aug 2022 14:37:49 +0200	[thread overview]
Message-ID: <20220812123749.zqqn4kico5zai5ql@pengutronix.de> (raw)
In-Reply-To: <CAMgOUGoKHJnA5KLBE5_txgEBnC6LU3zNKkok7QEiMcrwQc0TvA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2875 bytes --]

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 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-08-12 12:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-10  2:35 PCAN and SocketCAN Questions David Boles
2022-08-10  7:45 ` Marc Kleine-Budde
2022-08-11 20:17   ` David Boles
2022-08-12 12:37     ` Marc Kleine-Budde [this message]
2022-08-12 13:00       ` Oliver Hartkopp
2022-08-12 19:00         ` David Boles
2022-08-12 18:49       ` David Boles

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220812123749.zqqn4kico5zai5ql@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=me@davidbol.es \
    --cc=s.grosjean@peak-system.com \
    --cc=thomasaevans@optusnet.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox