Re: What are you doing if the TX buffer overflows?

[Jason White <white_jason_r1@cat.com>]

Marc Kleine-Budde <mkl <at> pengutronix.de> writes:

> 
> 
> We have several customers who asked how to abort pending TX messages,
> too. Which involves:
> a) clear the TX-queue in Linux
> b) clear queue in hardware
> c) abort currently transmitting CAN frame
> 
> I think c) would be a usecase of its own, too.
> 
> Marc
> 


Has there been any more investigation into this tx buffer overflow scenario?

I've been working on using SocketCAN interface for the past several months.  
I have quite a bit of experience with CAN from an embedded perspective 
(outside of Linux) and even multiple clients accessing a single CAN port.  
We have to have a method of flushing the transmit queue because if an ECU is 
initially alone on the network and goes error passive (no ack), then we want
to be able to flush the tx queue periodically to prevent stale data on the bus.
Other scenarios have also been listed.

Right now we are taking the interface down and then back up and while this 
works for a single process using CAN, I don't think it will work well with 
multi-process support.  Would the other processes know that the interface 
was taken down?  I haven't decided the route we will go, but maybe an 
intermediate layer between SocketCAN and user processes to monitor the 
flushing.  Does the socket itself have any buffering or are messages 
forwarded directly to the driver?

Ideally a packet timeout would be implemented in the driver since it knows 
when the last message was transmitted (tx interrupt) and could perform the 
flush properly.  Has there been any more thought to this scenario?

Thanks,
Jason