Re: mcp251xfd receiving non ACKed frames (was: Re: More flags for logging)

[Vincent MAILHOL <mailhol.vincent@wanadoo.fr>]

On Tue. 4 Mai 2021 at 21:22, Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote:
> On Mar. 4 Mai 2021 at 16:48, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> > On 04.05.2021 06:46:17, Vincent MAILHOL wrote:
[...]
> > > Are you still able to send frames and receive the echo if there is a
> > > single node on the network?
> >
> > No - But the peak driver/hw has some limitations:
> >
> > The peak driver doesn't have TX complete signaling, it send the echo
> > after sending the TX CAN frame via USB. And the peak controller seems to
> > buffer quite a lot TX CAN frames, so it looks for the first ~72 frames
> > like the bus is still working.
>
> Yes, I also noticed that when I had peak devices in my test
> lab. The peak driver call can_put_echo_skb() inside
> peak_usb_ndo_start_xmit() and thus, the echo frames do not
> reflect whether the actual completion occured or not. I guess
> fixing that should not be too hard but I do not have access to
> that hardware anymore to do it myself.
>
> I am just surprised by the value of 72 frames. My understanding
> is that peak_usb_ndo_start_xmit() should stop the network queue
> whenever the number of active tx urbs reaches 10.
> Ref:
> https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/peak_usb/pcan_usb_core.c#L399
> https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/peak_usb/pcan_usb_core.h#L29

Hi Marc, please ignore above paragraphs. I mixed up the tx buffer
with the TX frame buffer. Also, implementing a full TX completion
might actually not be possible due to the Peak device
limitations.