Re: CM-ITC, pch_can/c_can_pci, sendto() returning ENOBUFS - Marc Kleine-Budde

From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Jacob Kroon <jacob.kroon@gmail.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>, linux-can@vger.kernel.org
Subject: Re: CM-ITC, pch_can/c_can_pci, sendto() returning ENOBUFS
Date: Mon, 5 Sep 2022 16:17:43 +0200	[thread overview]
Message-ID: <20220905141743.2hqexc3gmzzgdgly@pengutronix.de> (raw)
In-Reply-To: <c1c8bbbe-4282-1dc4-db20-a21b55eecc14@gmail.com>

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

On 02.09.2022 17:13:46, Jacob Kroon wrote:
> Thank you Oliver for all the good hints.
> 
> I've done some more logging, but there are no error frames being logged.
> 
> I can see that both pch_can and c_can_pci drivers call can_put_echo_skb() in
> their ndo_start_xmit functions, but neither checks the return value whether
> it succeeded or not. Shouldn't both these return NETDEV_TX_BUSY if there are
> no echo slots available ?

No - The TX queue between the kernel and the driver should only be
active in the first place if there is room in the hardware TX queue. If
there is room in the hardware TX queue, there's room in the echo skb
array, too.

> One reason I ask is because whenever I strace the application, it would seem
> the problem goes away, and I'm guessing strace:ing will slow down my
> application.

ACK - strace slows down the app, probably resulting in the TX queue not
run full.

If I find some time I can try to reproduce the problem on a beagle bone,
which uses d_can core. Just got back from holidays, so I'm quite busy
right now. Drop me a note, if you need commercial support.

regards,
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 --]