Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Mon, 9 May 2022 21:04:06 +0200
From:   Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
To:     Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
Cc:     Robin van der Gracht <robin@protonic.nl>,
        Oleksij Rempel <o.rempel@pengutronix.de>,
        kernel@pengutronix.de, linux-can@vger.kernel.org,
        Oleksij Rempel <linux@rempel-privat.de>,
        Oliver Hartkopp <socketcan@hartkopp.net>,
        Marc Kleine-Budde <mkl@pengutronix.de>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Maxime Jayat <maxime.jayat@mobile-devices.fr>,
        kbuild test robot <lkp@intel.com>, 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: <YnllpntZ8V5CD07v@x1.vandijck-laurijssen.be>
Mail-Followup-To: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>,
        Robin van der Gracht <robin@protonic.nl>,
        Oleksij Rempel <o.rempel@pengutronix.de>, kernel@pengutronix.de,
        linux-can@vger.kernel.org, Oleksij Rempel <linux@rempel-privat.de>,
        Oliver Hartkopp <socketcan@hartkopp.net>,
        Marc Kleine-Budde <mkl@pengutronix.de>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
        Maxime Jayat <maxime.jayat@mobile-devices.fr>,
        kbuild test robot <lkp@intel.com>, 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>
Precedence: bulk

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