From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
Cc: Robin van der Gracht <robin@protonic.nl>,
Oleksij Rempel <linux@rempel-privat.de>,
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
Subject: Re: [PATCH v2] can: j1939: do not wait 250 ms if the same addr was already claimed
Date: Sat, 26 Nov 2022 11:28:40 +0100 [thread overview]
Message-ID: <20221126102840.GA21761@pengutronix.de> (raw)
In-Reply-To: <20221125170418.34575-1-devid.filoni@egluetechnologies.com>
On Fri, Nov 25, 2022 at 06:04:18PM +0100, Devid Antonio Filoni wrote:
> 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>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> 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
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2022-11-26 10:28 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 ` [PATCH v2] can: j1939: do not wait 250 ms " Devid Antonio Filoni
2022-11-26 10:28 ` Oleksij Rempel [this message]
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=20221126102840.GA21761@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=davem@davemloft.net \
--cc=devid.filoni@egluetechnologies.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).