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

[Jason White <white_jason_r1@cat.com>]

Marc Kleine-Budde <mkl@pengutronix.de> wrote on 11/15/2012 06:54:20 AM:

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

But you wouldn't want all processes to implement this timeout, otherwise 
they would all timeout at the same time and bring the interface down 
hence having something lower down in the stack implement it. 


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

Every piece of CAN hardware I've seen (10+ devices) has a tx interrupt 
that indicates when the message is transmitted.  If the current message 
being transmitted has been in the buffer XX amount of time, then it 
and probably the entire queue should be flushed.  Obviously not all 
hardware supports aborting the current frame, but there are work arounds. 
Usually if a CAN message can't transmit within this time it's data is way 
too old to be sent.  The actual time might be up for discussion and 
depends on what is being sent, but for controls its not that long. 

Jason