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

[Wolfgang Grandegger <wg@grandegger.com>]

On 09/19/2012 09:39 AM, Marc Kleine-Budde wrote:
> On 09/19/2012 08:50 AM, Wolfgang Grandegger wrote:
>> On 09/18/2012 10:20 PM, Kurt Van Dijck wrote:
>>> On Tue, Sep 18, 2012 at 09:13:48PM +0200, Wolfgang Grandegger wrote:
>>>> On 09/18/2012 09:01 PM, Marc Kleine-Budde wrote:
>>>>> On 09/18/2012 08:50 PM, Wolfgang Grandegger wrote:
>>>>>> On 09/18/2012 03:42 PM, Marc Kleine-Budde wrote:
>>>>>>> On 09/18/2012 03:39 PM, Wolfgang Grandegger wrote:
>>>>>>>> On 09/18/2012 03:00 PM, Marc Kleine-Budde wrote:
>>>>>>>>> On 09/18/2012 02:49 PM, Wolfgang Grandegger wrote:
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> I think you need c) for b), at least for some controllers. These
>>>>>>>>>
>>>>>>>>> Yes, if it's a hardware limitation so be it. But if we design an
>>>>>>>>> interface it should support "clear everything" (a+b+c), but also just
>>>>>>>>> only c.
>>>>>>>>
>>>>>>>> Yes, that you be nice. The only portable "clear everything" (a+b+c) I
>>>>>>>> see is "ifconfig down -> up". This also answers you other related mail.
>>>>>>>>
>>>>>>>> What do people really want/need and why? This is still not clear to me.
>>>>>>>> More input would be nice.
>>>>>>>
>>>>>>> Heinz-Jürgen uses abort current TX Message on SJA1000, can you give us
>>>>>>> more insight? I've talked to customers, e.g. they want to abort the
>>>>>>> current frame if it takes "too long" to send it, because the frames CAN
>>>>>>> id priority is too low.
>>>
>>> If "too long" is defined as a period of time where it makes sense to
>>> take such actions in software (like > 10msec), and your message still
>>> did not get out, but you wanted it to be,
>>> then IMO the bus load is too high with regard to the expected time restrictions.
>>>
>>> Or am I missing something?
>>>
>>>>>>
>>>>>> What we could implement rather easily is a "tx-abort-last" or
>>>>>> "tx-abort-all" netlink command. As this command does not make sense when
>>>>>> more than one message is pending I'm in favor of "tx-abort-last".
>>>>>
>>>>> I like to have both commands.
>>>>
>>>> But then "tx-abort-all" should also clear the tx socket queue. Also be
>>>> aware that more than one socket may send messages. Let's wait for more
>>>> use-cases.
>>>
>>> I'm afraid tx-abort-all & tx-abort-last cause more damage than good,
>>> especially, but not only, in multi-user environments.
>>
>> At least it's incompatible with multi-user (-sender) support and it does
>> not fit into the Linux networking principles! And so far I have not
>> heard strong arguments for implementing message flush and abort. I still
>> believe that a device stop->restart is enough to cure such problems. But
>> let's wait and see.
> 
> Network stop->start does basically drain all buffers (software +
> hardware + frame currently sending). Just remove the currently tx-ing
> frame is a valid use case, and ifconfig down; ifconfig  up has some
> drawbacks:
> - a transceiver (if controlled by the driver) will be switched
>   off and on.
> - the clocks will be turned off and on
> - there might be some "mdelay" or "msleep" loops during hw/sw reset

Before doing this, the controller goes bus-off. Therefore it should not
harm.

> In case the hardware a clear hw fifo and abort current tx frame there

What would clear hw fifo be good for? Then, for portability reasons I
would vote for tx-abort-all, which does both. As the app does not known
which message is currently transmitted, that does make sense to me.

> might be a much faster and cleaner way.

Well, it does not need to be fast because the bus is blocked anyway and
the support will be heavily hardware dependent. Anyway, till now I have
not seen a good use-case (apart from the vague one you mentioned). I'm
also afraid of mis-using such a feature.

Wolfgang.