> On 17.10.2022 14:55:58, Sebastien FABRE wrote: > > Hello, > > > > I am working on 5.4 kernel, and I have the same behavior with 5.10 > > kernel version. > > > > I reproduce the behavior with a custom application. A j1939 socket is > > created with SO_BROADCAST and SO_J1939_PROMISC options and is binded. > > The application sends a claim message then 50 broadcast messages in > > loop (without waiting) with size greater than 8 bytes (50). > > > > Every sendto methods return success directly and sessions are stored > > in sk_session_queue. > > > > If the can is 'on' but nobody acknowledges, after some times, trames > > are no longer sent (ENOBUFS) but the application does not have this > > information (sendto returned success). > > > > Moreover, txqueuelen does not have impact to this behavior (queue size > > seems to be infinite). > > > > To finish, closing socket will take a long time depending on > > sk_session_queue size because of J1939_XTP_TX_RETRY_LIMIT: kernel > > seems to try to send every message 100 times if ENOBUFS is received. > > > > Is it the expected behavior? How can the application know that > > messages are no longer sent? > > It's sort of expected....I think we haven't thought of that corner case. > There is the socket TX timeout option, seems we have to implement this for > j1939. > I reproduced the same behaviour with updated testj1939 (so no claim message) to be able to send multiple messages. The tests have been done with peak can or flexcan. Should we limit the sk_session_queue size to not be able to have too many messages in this queue ? In this case, sendto will return an error (and not success) when it is full. Regards, Sébastien Fabre
