From: Simon Wunderlich <sw@simonwunderlich.de>
To: netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
b.a.t.m.a.n@lists.open-mesh.org,
Sven Eckelmann <sven@narfation.org>,
Simon Wunderlich <sw@simonwunderlich.de>
Subject: [PATCH net-next 15/15] batman-adv: tp_meter: delay allocation of unacked entry
Date: Tue, 30 Jun 2026 16:06:23 +0200 [thread overview]
Message-ID: <20260630140623.88431-16-sw@simonwunderlich.de> (raw)
In-Reply-To: <20260630140623.88431-1-sw@simonwunderlich.de>
From: Sven Eckelmann <sven@narfation.org>
When batadv_tp_handle_out_of_order() searches the already existing list of
unacked packets, it can often find an entry to merge with. In this case, it
would be a waste of time and resources to allocate a batadv_tp_unacked
which is then immediately freed again.
Instead, search first through the list. Only when no mergeable entry could
be found, it is necessary to record the place to allocate+store the new
entry.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/tp_meter.c | 88 ++++++++++++++++++---------------------
1 file changed, 41 insertions(+), 47 deletions(-)
diff --git a/net/batman-adv/tp_meter.c b/net/batman-adv/tp_meter.c
index ffd3171d4b992..00467aa79de9d 100644
--- a/net/batman-adv/tp_meter.c
+++ b/net/batman-adv/tp_meter.c
@@ -1417,26 +1417,15 @@ static bool batadv_tp_handle_out_of_order(struct batadv_tp_receiver *tp_vars,
u32 seqno, u32 payload_len)
__must_hold(&tp_vars->ack_seqno_lock)
{
- struct batadv_tp_unacked *un, *new;
+ struct list_head *pos = &tp_vars->unacked_list;
+ struct batadv_tp_unacked *new = NULL;
+ u32 end_seqno = seqno + payload_len;
struct batadv_tp_unacked *safe;
- bool added = false;
-
- new = kmalloc_obj(*new, GFP_ATOMIC);
- if (unlikely(!new))
- return false;
-
- new->seqno = seqno;
- new->len = payload_len;
-
- /* if the list is empty immediately attach this new object */
- if (list_empty(&tp_vars->unacked_list)) {
- list_add(&new->list, &tp_vars->unacked_list);
- tp_vars->unacked_count++;
- return true;
- }
+ struct batadv_tp_unacked *un;
- /* otherwise loop over the list and either drop the packet because this
- * is a duplicate or store it at the right position.
+ /* loop over the list to find either an existing entry which the new
+ * seqno range can be merged with or the position at which a new entry
+ * has to be inserted.
*
* The iteration is done in the reverse way because it is likely that
* the last received packet (the one being processed now) has a bigger
@@ -1444,7 +1433,7 @@ static bool batadv_tp_handle_out_of_order(struct batadv_tp_receiver *tp_vars,
*/
list_for_each_entry_reverse(un, &tp_vars->unacked_list, list) {
/* look for the right position - an un which is smaller */
- if (batadv_seq_before(new->seqno, un->seqno))
+ if (batadv_seq_before(seqno, un->seqno))
continue;
/* smaller/equal seqno was found but they might be directly
@@ -1452,62 +1441,67 @@ static bool batadv_tp_handle_out_of_order(struct batadv_tp_receiver *tp_vars,
*
* It is already known that:
*
- * un->seqno <= new->seqno
+ * un->seqno <= seqno
*
* When establishing that:
*
- * new->seqno <= un->seqno + un->len
+ * seqno <= un->seqno + un->len
*
* Then it is not necessary to add a new entry because the
* smaller/equal seqno of un might already contain the new
* received packet or we only add new data directly after
* the end of un. The latter can be identified using:
*
- * un->seqno + un->len <= new->seqno + new->len
+ * un->seqno + un->len <= end_seqno
*/
- if (!batadv_seq_before(un->seqno + un->len, new->seqno)) {
+ if (!batadv_seq_before(un->seqno + un->len, seqno)) {
/* new data directly after un? */
- if (!batadv_seq_before(new->seqno + new->len,
- un->seqno + un->len))
- un->len = new->seqno + new->len - un->seqno;
+ if (!batadv_seq_before(end_seqno, un->seqno + un->len))
+ un->len = end_seqno - un->seqno;
- /* un now represents both old un + new */
- kfree(new);
- added = true;
-
- /* un has to be used to check if the gap to the next
- * seqno range was closed
+ /* un now represents both old un + new range and has to
+ * be used to check if the gap to the next seqno range
+ * was closed
*/
new = un;
- break;
+ } else {
+ /* as soon as an entry having a smaller seqno is found,
+ * the new one is attached _after_ it. In this way the
+ * list is kept in ascending order
+ */
+ pos = &un->list;
}
- /* as soon as an entry having a smaller seqno is found, the new
- * one is attached _after_ it. In this way the list is kept in
- * ascending order
- */
- list_add(&new->list, &un->list);
- added = true;
- tp_vars->unacked_count++;
break;
}
- /* received packet with smallest seqno out of order; add it to front */
- if (!added) {
- list_add(&new->list, &tp_vars->unacked_list);
+ /* no entry to merge with was found; insert a new one after the entry
+ * with the next smaller seqno (or at the front of the list when the
+ * new seqno is the smallest or the list is empty)
+ */
+ if (!new) {
+ new = kmalloc_obj(*new, GFP_ATOMIC);
+ if (unlikely(!new))
+ return false;
+
+ new->seqno = seqno;
+ new->len = payload_len;
+
+ list_add(&new->list, pos);
tp_vars->unacked_count++;
}
/* check if new filled the gap to the next list entries */
un = new;
list_for_each_entry_safe_continue(un, safe, &tp_vars->unacked_list, list) {
- if (batadv_seq_before(new->seqno + new->len, un->seqno))
+ if (batadv_seq_before(end_seqno, un->seqno))
break;
/* next entry is overlapping or adjacent - combine both */
- if (batadv_seq_before(new->seqno + new->len,
- un->seqno + un->len))
- new->len = un->seqno + un->len - new->seqno;
+ if (batadv_seq_before(end_seqno, un->seqno + un->len)) {
+ end_seqno = un->seqno + un->len;
+ new->len = end_seqno - new->seqno;
+ }
list_del(&un->list);
kfree(un);
--
2.47.3
prev parent reply other threads:[~2026-06-30 14:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 14:06 [PATCH net-next 00/15] pull request for net-next: batman-adv 2026-06-30 Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 01/15] batman-adv: create hardif only for netdevs that are part of a mesh Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 02/15] batman-adv: remove global hardif list Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 03/15] batman-adv: make hard_iface->mesh_iface immutable Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 04/15] batman-adv: remove BATADV_IF_NOT_IN_USE hardif state Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 05/15] batman-adv: move hardif generation counter into batadv_priv Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 06/15] batman-adv: drop unneeded goto and initialization from batadv_hardif_disable_interface() Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 07/15] batman-adv: drop NULL check for immutable hardif->mesh_iface Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 08/15] Revert "batman-adv: v: stop OGMv2 on disabled interface" Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 09/15] batman-adv: iv: drop migration check for batadv_hard_iface Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 10/15] batman-adv: tvlv: extract tvlv header iterator Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 11/15] batman-adv: tp_meter: simplify unordered ack calculation Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 12/15] batman-adv: tp_meter: combine adjacent/overlapping unacked entries Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 13/15] batman-adv: tp_meter: keep unacked list for receivers Simon Wunderlich
2026-06-30 14:06 ` [PATCH net-next 14/15] batman-adv: tp_meter: adjust name of receiver lock Simon Wunderlich
2026-06-30 14:06 ` Simon Wunderlich [this message]
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=20260630140623.88431-16-sw@simonwunderlich.de \
--to=sw@simonwunderlich.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sven@narfation.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