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

[Wolfgang Grandegger <wg@grandegger.com>]

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

Wolfgang.