From: Jules Maselbas <jmaselbas@kalray.eu>
To: barebox@lists.infradead.org
Cc: Jules Maselbas <jmaselbas@kalray.eu>
Subject: [RFC PATCH] ratp: Fix retransmission for header-only packets
Date: Mon, 23 Jan 2023 11:27:52 +0100 [thread overview]
Message-ID: <20230123102752.15444-1-jmaselbas@kalray.eu> (raw)
Using sendmsg_current to detect if a packet needs to be retransmitted is
brittle as only packets containing data will ever be considered, packets
only containing a header (without data) were never being retransmitted.
The sendbuf_len is used to determine if a packets is being send or not,
a non-zero length means that a packets is still being in the "try-send"
state, the length is not set to zero when a valid SN is received.
Retransmission issue can be easily reproduced with a physical UART (not
cdc_acm over USB), by running the following command:
while ratp-barebox-cli -b 115200 -t /dev/ttyACMx -p; do :; done
Alternatively, it is possible to modify lib/ratp.c to force packets to
be sent by the retransmission logic with the following change:
@ int ratp_send_pkt(struct ratp_internal *ri, void *pkt, int length)
ri->sendbuf_len = length;
- ri->retransmission_timer_start = get_time_ns();
+ ri->retransmission_timer_start = get_time_ns() - ri->rto * MSECOND/2;
ri->retransmission_count = 0;
}
- return ri->ratp->send(ri->ratp, pkt, length);
+ return 0;
Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu>
---
lib/ratp.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/ratp.c b/lib/ratp.c
index ce30223bac..afa76ac894 100644
--- a/lib/ratp.c
+++ b/lib/ratp.c
@@ -1391,6 +1391,9 @@ static int ratp_state_machine(struct ratp_internal *ri, void *pkt)
ratp_print_header(ri, hdr, " recv");
pr_debug(" state %s\n", ratp_state_str[ri->state]);
+ if ((hdr->control & RATP_CONTROL_ACK) && (ratp_an_expected(ri, hdr)))
+ ri->sendbuf_len = 0;
+
switch (ri->state) {
case RATP_STATE_LISTEN:
ratp_behaviour_a(ri, pkt);
@@ -1580,9 +1583,8 @@ int ratp_poll(struct ratp *ratp)
}
}
- if (ri->sendmsg_current && is_timeout(ri->retransmission_timer_start,
+ if (ri->sendbuf_len && is_timeout(ri->retransmission_timer_start,
ri->rto * MSECOND)) {
-
ri->retransmission_count++;
if (ri->retransmission_count == ri->max_retransmission) {
ri->status = ret = -ETIMEDOUT;
@@ -1601,7 +1603,7 @@ int ratp_poll(struct ratp *ratp)
goto out;
}
- if (!ri->sendmsg_current && !list_empty(&ri->sendmsg))
+ if (ri->sendbuf_len == 0 && !list_empty(&ri->sendmsg))
ratp_send_next_data(ri);
ret = 0;
--
2.17.1
next reply other threads:[~2023-01-23 10:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 10:27 Jules Maselbas [this message]
2023-01-25 15:39 ` [PATCH v2] " Jules Maselbas
2023-01-25 15:44 ` Jules Maselbas
2023-02-03 8:16 ` Sascha Hauer
2023-02-05 17:07 ` Jules Maselbas
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=20230123102752.15444-1-jmaselbas@kalray.eu \
--to=jmaselbas@kalray.eu \
--cc=barebox@lists.infradead.org \
/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