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

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

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

On 09/19/2012 07:42 AM, Oliver Hartkopp wrote:
[...]

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

I was just describing the use case for a "abort-current-tx" command. The
it takes "too long" and then abort will be implemented in the userspace.
But without a "abort-current-tx" command this is not possible. It was
not my intention to propose to implement an automatic abort if message
is too old in the kernel as a framework option.

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

No, see above.

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

I don't want to check for expired frames in 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.

You mean a "in-band" skb that kills out-dated CAN frames? No, no inband
magic, please.

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