From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22158C433EF for ; Mon, 9 May 2022 19:16:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240499AbiEITUD (ORCPT ); Mon, 9 May 2022 15:20:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240474AbiEITUB (ORCPT ); Mon, 9 May 2022 15:20:01 -0400 X-Greylist: delayed 711 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 09 May 2022 12:16:04 PDT Received: from relay-b03.edpnet.be (relay-b03.edpnet.be [212.71.1.220]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A361A54BE3 for ; Mon, 9 May 2022 12:16:03 -0700 (PDT) X-ASG-Debug-ID: 1652123048-15c435381a966b00001-BZBGGp Received: from srv21.vandijck-laurijssen.be (77.109.97.42.adsl.dyn.edpnet.net [77.109.97.42]) by relay-b03.edpnet.be with ESMTP id evQvZkMsT4fx48c7; Mon, 09 May 2022 21:04:08 +0200 (CEST) X-Barracuda-Envelope-From: dev.kurt@vandijck-laurijssen.be X-Barracuda-Effective-Source-IP: 77.109.97.42.adsl.dyn.edpnet.net[77.109.97.42] X-Barracuda-Apparent-Source-IP: 77.109.97.42 Received: from x1.vandijck-laurijssen.be (x1.vandijck-laurijssen.be [IPv6:fd01::1a1d:eaff:fe02:d339]) by srv21.vandijck-laurijssen.be (Postfix) with ESMTPSA id 0E1DA1063BE; Mon, 9 May 2022 21:04:08 +0200 (CEST) Date: Mon, 9 May 2022 21:04:06 +0200 From: Kurt Van Dijck To: Devid Antonio Filoni Cc: Robin van der Gracht , Oleksij Rempel , kernel@pengutronix.de, linux-can@vger.kernel.org, Oleksij Rempel , Oliver Hartkopp , Marc Kleine-Budde , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Maxime Jayat , kbuild test robot , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] can: j1939: do not wait 250ms if the same addr was already claimed Message-ID: X-ASG-Orig-Subj: Re: [PATCH RESEND] can: j1939: do not wait 250ms if the same addr was already claimed Mail-Followup-To: Devid Antonio Filoni , Robin van der Gracht , Oleksij Rempel , kernel@pengutronix.de, linux-can@vger.kernel.org, Oleksij Rempel , Oliver Hartkopp , Marc Kleine-Budde , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Maxime Jayat , kbuild test robot , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220509170303.29370-1-devid.filoni@egluetechnologies.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220509170303.29370-1-devid.filoni@egluetechnologies.com> X-Barracuda-Connect: 77.109.97.42.adsl.dyn.edpnet.net[77.109.97.42] X-Barracuda-Start-Time: 1652123048 X-Barracuda-URL: https://212.71.1.220:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at edpnet.be X-Barracuda-Scan-Msg-Size: 1034 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.97894 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On ma, 09 mei 2022 19:03:03 +0200, Devid Antonio Filoni wrote: > This is not explicitly stated in SAE J1939-21 and some tools used for > ISO-11783 certification do not expect this wait. IMHO, the current behaviour is not explicitely stated, but nor is the opposite. And if I'm not mistaken, this introduces a 250msec delay. 1. If you want to avoid the 250msec gap, you should avoid to contest the same address. 2. It's a balance between predictability and flexibility, but if you try to accomplish both, as your patch suggests, there is slight time-window until the current owner responds, in which it may be confusing which node has the address. It depends on how much history you have collected on the bus. I'm sure that this problem decreases with increasing processing power on the nodes, but bigger internal queues also increase this window. It would certainly help if you describe how the current implementation fails. Would decreasing the dead time to 50msec help in such case. Kind regards, Kurt