On Tue, Aug 06, 2019 at 05:50:13PM +0200, David Jander wrote: > On Tue, 6 Aug 2019 14:52:45 +0200 > Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > > > Hi all, > > > > On Tue, Jul 23, 2019 at 10:59:07AM +0200, Marc Kleine-Budde wrote: > > > On 7/22/19 3:37 PM, Oleksij Rempel wrote: > > > > We just noticed, in current implementation J1939_SOCK_RECV_OWN doesn't > > > > work anymore (for ETP). And ...naively thinking it probably makes no > > > > sense to support it for different reasons: > > > > > > > > - we have a better feedback mechanism via the error queue feature > > > > - with RECV_OWN the socket receives the complete payload back into user > > > > space, where the error queue will give back message number at state of > > > > the message/transfer. > > > > - the error queue mechanism is extendable with more information and even > > > > backwards compatible. > > > > > > > > However in the current implementation you'll receive an ACK via error > > > > queue if the (E)TP transfer is completed, but for simple messages, the > > > > ACK is received as soon as the packet has been put into the packet > > > > scheduler. It would be better to wait and send the ACK only after the > > > > simple message has been send onto the wire (i.e.: after the CAN > > > > controller's TX-complete interrupt). > > > > > > > > We'll remove J1939_SOCK_RECV_OWN for now. > > > > > > > > But we already noticed that this will break jacd, however we think we > > > > can fix it, by using a separate socket to receive. Are there any other > > > > use cases or existing applications relying on this feature? > > > > > > I think in AGL they switch on self reception of j1939 sockets by default. > > > > I have implemented missing functionality to monitor and "ACK" simple > > (<9 byte) packages. Users space will get same kind of notifications over > > the error queue: > > - SCHED - means, the packages was scheduled and will be soon taken over > > by hardware for transmission to the CAN bus. > > - ACK - CAN HW transmitted the package and send the echo signal back to > > the J1939 stack. > > - ABORT - we was no able to schedule the package or receive the > > transmit confirmation. > > Does that mean that for every message sent by user-space, user-space will get > woken up two more times? > This sounds like a lot of context switching overhead to me... I hope SCHED > and/or ACK can be disabled? > ACK The error queue is disabled by default, to enabled it you need to use sockopt SO_J1939_ERRQUEUE. ACK should be enabled by SOF_TIMESTAMPING_TX_ACK and SCHED enabled by SOF_TIMESTAMPING_TX_SCHED > > In current kernel implementation, ABORT can be not 100% true. In case > > CAN bus is open and get "fixed"/closed after some time, ABORTed packages > > still may be transmitted to the bus. With current J1939 implementation > > we are able to detect it. In kernel log you will see: > > flexcan 2090000.flexcan can0: j1939_simple_recv: Received already > > invalidated message > > > > This issue can be fixed, at least for some drivers or hardware, in the CAN > > framework (not in J1939 stack). > > > > Since this problem was present with previous J1939 stack version and > > no good way to track transmitted packages, I don't see it as a regression. > > > > The jacd needed a 3 line change to make it work without > > J1939_SOCK_RECV_OWN flag. So, probably other projects, we be able to fix > > it as well. Best regards, Oleksij -- 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 |
