Hi all,
after using and testing ETP long transfers I have following questions
1. Support for idle (E)TP
In case user space application is sending an (E)TP transfer and is not
scheduled due to other process with higher priority, the loop in
j1939_sk_send_multi() will not be able to fill the tp send queue with data.
If the queue runs empty the sending side will not be able to send any more
data, resulting in a TX abort on the receiving side. Which terminates the
session on the TX side, too.
In order to avoid this, send (E)TP idle packages, if the TX queue is empty.
I hope it is a proper way to handle it. What is you experience in
this case?
2. Handle properly signals
In case user space application is sending an (E)TP transfer and receives a signal
we should properly handle it.
Examples:
- Attach to a process sending a (E)TP via "strace -p PID" or ctrl+z followed by "fg",
j1939_sk_alloc_skb() will set ret to -512 (ERESTARTSYS). If we pass this
error to userspace, the glibc will restart the "sendto()" automatically,
without the userspace application itself noticing the problem.
In the kernel space j1939_sk_send_multi() will not detect this restart
for now, creating a new session. The old session will run into a queue
underrun.
Currently I'm not sure how it should be properly handled. Should we try
to detect if it is still the same session and try to continue it? For
maximal ETP transfer we will need 1 or 2 days, so braking it just in the
middle for strace or gdb will make it hard to debug.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
