On 29.08.2021 22:14:41, Oliver Hartkopp wrote:

quoted

quoted

IMO the issue arises with the use of isotpsend and isotprecv.
These tools are intended to get a hands-on impression how the isotp
stack works.

This kind of use in a script leads to the creation and (now delayed)
*removal* of isotp sockets for *each* single PDU transfer.

Maybe I am wrong but I see something different.
e.g. without this patch:
  (000.000240)  canfd0  714   [8]  2B 01 01 01 01 01 01 01
  (000.000261)  canfd0  77E   [8]  30 0F 00 AA AA AA AA AA
  (000.000496)  canfd0  714   [8]  2C 01 01 01 01 01 01 01

and with this patch:
  (000.000414)  canfd0  714   [8]  2B 01 01 01 01 01 01 01
  (000.000262)  canfd0  77E   [8]  30 0F 00 AA AA AA AA AA
  (000.001536)  canfd0  714   [8]  2C 01 01 01 01 01 01 01

I'm running a 5.14.0-rc7-00011-g6e764bcd1cf7 kernel here and see this:

 (000.000001)  vcan0  714   [8]  2B 01 01 01 01 01 01 01
 (000.000015)  vcan0  77E   [8]  30 0F 00 AA AA AA AA AA
 (000.000005)  vcan0  714   [8]  2C 01 01 01 01 01 01 01

Test iso-tp with 1000 byte frames on vcan0 (data:01)
    1 / curr:   40 / min:   40 / max:   40 / avg:   40.0
    2 / curr:   30 / min:   30 / max:   40 / avg:   35.0
    3 / curr:   35 / min:   30 / max:   40 / avg:   35.0
    4 / curr:   52 / min:   30 / max:   52 / avg:   39.2
    5 / curr:   40 / min:   30 / max:   52 / avg:   39.4
(..)

when running your scripts from the initial post.

Is you canfd0 interface a real hardware?

I can reproduce the issue here, on an embedded system with a real
hardware CAN interface.

In j1939 we make use of rcu so that we don't need the synchronize_net().
Is it possible to use this is ISOTP, too?

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |