All of lore.kernel.org
 help / color / mirror / Atom feed
From: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
To: Robin van der Gracht <robin@protonic.nl>,
	Oleksij Rempel <linux@rempel-privat.de>
Cc: kernel@pengutronix.de, Oliver Hartkopp <socketcan@hartkopp.net>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-can@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
Subject: [PATCH v2] can: j1939: do not wait 250 ms if the same addr was already claimed
Date: Fri, 25 Nov 2022 18:04:18 +0100	[thread overview]
Message-ID: <20221125170418.34575-1-devid.filoni@egluetechnologies.com> (raw)
In-Reply-To: <20221124051611.GA7870@pengutronix.de>

The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states:
  d) No CF shall begin, or resume, transmission on the network until 250
     ms after it has successfully claimed an address except when
     responding to a request for address-claimed.

But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
prioritization" show that the CF begins the transmission after 250 ms
from the first AC (address-claimed) message even if it sends another AC
message during that time window to resolve the address contention with
another CF.

As stated in "4.4.2.3 - Address-claimed message":
  In order to successfully claim an address, the CF sending an address
  claimed message shall not receive a contending claim from another CF
  for at least 250 ms.

As stated in "4.4.3.2 - NAME management (NM) message":
  1) A commanding CF can
     d) request that a CF with a specified NAME transmit the address-
        claimed message with its current NAME.
  2) A target CF shall
     d) send an address-claimed message in response to a request for a
        matching NAME

Taking the above arguments into account, the 250 ms wait is requested
only during network initialization.

Do not restart the timer on AC message if both the NAME and the address
match and so if the address has already been claimed (timer has expired)
or the AC message has been sent to resolve the contention with another
CF (timer is still running).

Signed-off-by: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
---
 v1 -> v2: Added ISO 11783-5 standard references

 net/can/j1939/address-claim.c | 40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/net/can/j1939/address-claim.c b/net/can/j1939/address-claim.c
index f33c47327927..ca4ad6cdd5cb 100644
--- a/net/can/j1939/address-claim.c
+++ b/net/can/j1939/address-claim.c
@@ -165,6 +165,46 @@ static void j1939_ac_process(struct j1939_priv *priv, struct sk_buff *skb)
 	 * leaving this function.
 	 */
 	ecu = j1939_ecu_get_by_name_locked(priv, name);
+
+	if (ecu && ecu->addr == skcb->addr.sa) {
+		/* The ISO 11783-5 standard, in "4.5.2 - Address claim
+		 * requirements", states:
+		 *   d) No CF shall begin, or resume, transmission on the
+		 *      network until 250 ms after it has successfully claimed
+		 *      an address except when responding to a request for
+		 *      address-claimed.
+		 *
+		 * But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
+		 * prioritization" show that the CF begins the transmission
+		 * after 250 ms from the first AC (address-claimed) message
+		 * even if it sends another AC message during that time window
+		 * to resolve the address contention with another CF.
+		 *
+		 * As stated in "4.4.2.3 - Address-claimed message":
+		 *   In order to successfully claim an address, the CF sending
+		 *   an address claimed message shall not receive a contending
+		 *   claim from another CF for at least 250 ms.
+		 *
+		 * As stated in "4.4.3.2 - NAME management (NM) message":
+		 *   1) A commanding CF can
+		 *      d) request that a CF with a specified NAME transmit
+		 *         the address-claimed message with its current NAME.
+		 *   2) A target CF shall
+		 *      d) send an address-claimed message in response to a
+		 *         request for a matching NAME
+		 *
+		 * Taking the above arguments into account, the 250 ms wait is
+		 * requested only during network initialization.
+		 *
+		 * Do not restart the timer on AC message if both the NAME and
+		 * the address match and so if the address has already been
+		 * claimed (timer has expired) or the AC message has been sent
+		 * to resolve the contention with another CF (timer is still
+		 * running).
+		 */
+		goto out_ecu_put;
+	}
+
 	if (!ecu && j1939_address_is_unicast(skcb->addr.sa))
 		ecu = j1939_ecu_create_locked(priv, name);
 
-- 
2.34.1


  reply	other threads:[~2022-11-25 17:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09 17:03 [PATCH RESEND] can: j1939: do not wait 250ms if the same addr was already claimed Devid Antonio Filoni
2022-05-09 19:04 ` Kurt Van Dijck
2022-05-10  4:26   ` Oleksij Rempel
2022-05-10 11:00     ` Devid Antonio Filoni
2022-05-11  8:47       ` Oleksij Rempel
2022-05-11  9:06         ` David Jander
2022-05-11 12:55           ` Devid Antonio Filoni
2022-05-11 14:22             ` David Jander
2022-05-13  9:46               ` Devid Antonio Filoni
2022-11-17 14:08                 ` Devid Antonio Filoni
2022-11-17 15:22                   ` David Jander
2022-11-18  6:06                     ` Oleksij Rempel
2022-11-18 10:25                       ` Devid Antonio Filoni
2022-11-18 12:30                         ` Oleksij Rempel
2022-11-18 12:41                           ` Devid Antonio Filoni
2022-11-18 13:44                             ` Oleksij Rempel
2022-11-18 15:12                               ` Devid Antonio Filoni
2022-11-19 10:12                                 ` Oleksij Rempel
2022-11-20  0:11                                   ` Devid Antonio Filoni
2022-11-20  8:45                                     ` Oleksij Rempel
2022-11-20 19:18                                       ` Devid Antonio Filoni
2022-11-21  5:19                                         ` Oleksij Rempel
2022-11-23 20:39                                           ` Devid Antonio Filoni
2022-11-24  5:16                                             ` Oleksij Rempel
2022-11-25 17:04                                               ` Devid Antonio Filoni [this message]
2022-11-26 10:28                                                 ` [PATCH v2] can: j1939: do not wait 250 ms " Oleksij Rempel
2023-02-07 13:50                                                   ` Devid Antonio Filoni
2023-02-07 14:05                                                     ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221125170418.34575-1-devid.filoni@egluetechnologies.com \
    --to=devid.filoni@egluetechnologies.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rempel-privat.de \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robin@protonic.nl \
    --cc=socketcan@hartkopp.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.