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

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 18.09.2012 22:20, 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?


The question is, if we should add some time of expiry to the tx-skb?!?

I have not checked whether the new ematch queuing discipline

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f057bbb6f9ed0fb61ea11105c9ef0ed5ac1a354d

http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf

would allow already to sort out expired skbs.

This is probably the preferred solution instead of checking expired skbs
inside the driver.
 

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


These netlink commands are/can be restricted to be used by root only.
Maybe for some special use-cases it makes sense to have them.

When draining the tx queues from the driver side, all skbs are purged.
I think this is not bound to a special socket instance then.

Summarizing i would suggest to check the expiring possibility of skbs (which
will kill out-dated CAN frames) - and only implement a tx-abort command that
kills the latest frame only.

Regards,
Oliver