From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: David Miller <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>, Jon Maloy <jon.maloy@ericsson.com>,
Erik Hugne <erik.hugne@ericsson.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: [PATCH net-next 01/10] tipc: remove obsolete flush of stale reassembly buffer
Date: Fri, 7 Dec 2012 09:28:09 -0500 [thread overview]
Message-ID: <1354890498-6448-2-git-send-email-paul.gortmaker@windriver.com> (raw)
In-Reply-To: <1354890498-6448-1-git-send-email-paul.gortmaker@windriver.com>
From: Erik Hugne <erik.hugne@ericsson.com>
Each link instance has a periodic job checking if there is a stale
ongoing message reassembly associated to the link. If no new
fragment has been received during the last 4*[link_tolerance] period,
it is assumed the missing fragment will never arrive. As a consequence,
the reassembly buffer is discarded, and a gap in the message sequence
occurs.
This assumption is wrong. After we abandoned our ambition to develop
packet routing for multi-cluster networks, only single-hop packet
transfer remains as an option. For those, all packets are guaranteed
to be delivered in sequence to the defragmentation layer. Any failure
to achieve sequenced delivery will eventually lead to link reset, and
the reassembly buffer will be flushed anyway.
So we just remove this periodic check, which is now obsolete.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: also delete get/inc_timer count, since they are now unused]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/link.c | 44 --------------------------------------------
1 file changed, 44 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 87bf5aa..daa6080 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -97,7 +97,6 @@ static int link_send_sections_long(struct tipc_port *sender,
struct iovec const *msg_sect,
u32 num_sect, unsigned int total_len,
u32 destnode);
-static void link_check_defragm_bufs(struct tipc_link *l_ptr);
static void link_state_event(struct tipc_link *l_ptr, u32 event);
static void link_reset_statistics(struct tipc_link *l_ptr);
static void link_print(struct tipc_link *l_ptr, const char *str);
@@ -271,7 +270,6 @@ static void link_timeout(struct tipc_link *l_ptr)
}
/* do all other link processing performed on a periodic basis */
- link_check_defragm_bufs(l_ptr);
link_state_event(l_ptr, TIMEOUT_EVT);
@@ -2497,16 +2495,6 @@ static void set_expected_frags(struct sk_buff *buf, u32 exp)
msg_set_bcast_ack(buf_msg(buf), exp);
}
-static u32 get_timer_cnt(struct sk_buff *buf)
-{
- return msg_reroute_cnt(buf_msg(buf));
-}
-
-static void incr_timer_cnt(struct sk_buff *buf)
-{
- msg_incr_reroute_cnt(buf_msg(buf));
-}
-
/*
* tipc_link_recv_fragment(): Called with node lock on. Returns
* the reassembled buffer if message is complete.
@@ -2585,38 +2573,6 @@ int tipc_link_recv_fragment(struct sk_buff **pending, struct sk_buff **fb,
return 0;
}
-/**
- * link_check_defragm_bufs - flush stale incoming message fragments
- * @l_ptr: pointer to link
- */
-static void link_check_defragm_bufs(struct tipc_link *l_ptr)
-{
- struct sk_buff *prev = NULL;
- struct sk_buff *next = NULL;
- struct sk_buff *buf = l_ptr->defragm_buf;
-
- if (!buf)
- return;
- if (!link_working_working(l_ptr))
- return;
- while (buf) {
- u32 cnt = get_timer_cnt(buf);
-
- next = buf->next;
- if (cnt < 4) {
- incr_timer_cnt(buf);
- prev = buf;
- } else {
- if (prev)
- prev->next = buf->next;
- else
- l_ptr->defragm_buf = buf->next;
- kfree_skb(buf);
- }
- buf = next;
- }
-}
-
static void link_set_supervision_props(struct tipc_link *l_ptr, u32 tolerance)
{
if ((tolerance < TIPC_MIN_LINK_TOL) || (tolerance > TIPC_MAX_LINK_TOL))
--
1.7.12.1
next prev parent reply other threads:[~2012-12-07 14:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 14:28 [PATCH net-next 00/10] tipc: more updates for the v3.8 content Paul Gortmaker
2012-12-07 14:28 ` Paul Gortmaker [this message]
2012-12-07 14:28 ` [PATCH net-next 02/10] tipc: eliminate aggregate sk_receive_queue limit Paul Gortmaker
2012-12-07 16:07 ` Neil Horman
2012-12-07 17:36 ` David Miller
2012-12-07 19:54 ` Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 03/10] tipc: sk_recv_queue size check only for connectionless sockets Paul Gortmaker
2012-12-07 19:20 ` Neil Horman
2012-12-07 22:30 ` Jon Maloy
2012-12-09 16:50 ` Neil Horman
2012-12-10 6:27 ` Ying Xue
2012-12-10 8:46 ` Jon Maloy
2012-12-10 14:22 ` Neil Horman
2012-12-07 14:28 ` [PATCH net-next 04/10] tipc: change sk_receive_queue upper limit Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 05/10] tipc: standardize across connect/disconnect function naming Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 06/10] tipc: consolidate connection-oriented message reception in one function Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 07/10] tipc: introduce non-blocking socket connect Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 08/10] tipc: eliminate connection setup for implied connect in recv_msg() Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 09/10] tipc: add lock nesting notation to quiet lockdep warning Paul Gortmaker
2012-12-07 14:28 ` [PATCH net-next 10/10] tipc: refactor accept() code for improved readability Paul Gortmaker
2012-12-07 19:42 ` Neil Horman
2012-12-07 19:56 ` Paul Gortmaker
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=1354890498-6448-2-git-send-email-paul.gortmaker@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=davem@davemloft.net \
--cc=erik.hugne@ericsson.com \
--cc=jon.maloy@ericsson.com \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).