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

[Marc Kleine-Budde <mkl@pengutronix.de>]

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

On 11/14/2012 09:48 PM, Jason White wrote:
> 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 

If the other process is doing a read, the read will return. I'm not sure
what happens to a write after ifdown/ifup, I think it will fail.

> 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?

This is a scenario, I think the first step will be to implement an
"abort currently transmitted frame" callback. Note that not all hardware
supports a tx-complete interrupt. A timeout mechanism can then be
implemented in the framework in a hardware independent way, e.g. if you
extend the currently used can_echo mechanism.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]