From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: James Chapman <jchapman@katalix.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] l2tp: make datapath resilient to packet loss when sequence numbers enabled
Date: Tue, 02 Jul 2013 20:32:56 +0400 [thread overview]
Message-ID: <51D300B8.4030807@cogentembedded.com> (raw)
In-Reply-To: <1372759229-15178-4-git-send-email-jchapman@katalix.com>
Hello.
On 02-07-2013 14:00, James Chapman wrote:
> If L2TP data sequence numbers are enabled and reordering is not
> enabled, data reception stops if a packet is lost since the kernel
> waits for a sequence number that is never resent. (When reordering is
> enabled, data reception restarts when the reorder timeout expires.) If
> no reorder timeout is set, we should count the number of in-sequence
> packets after the out-of-sequence (OOS) condition is detected, and reset
> sequence number state after a number of such packets are received.
> For now, the number of in-sequence packets while in OOS state which
> cause the sequence number state to be reset is hard-coded to 5. This
> could be configurable later.
> Signed-off-by: James Chapman <jchapman@katalix.com>
> ---
> net/l2tp/l2tp_core.c | 37 ++++++++++++++++++++++++++++++++-----
> net/l2tp/l2tp_core.h | 3 +++
> 2 files changed, 35 insertions(+), 5 deletions(-)
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index cc7ece9..f572e93 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -572,12 +572,34 @@ static int l2tp_recv_data_seq(struct l2tp_session *session, struct sk_buff *skb)
[...]
> + u32 nr_oos = L2TP_SKB_CB(skb)->ns;
> + u32 nr_next = (session->nr_oos + 1) & session->nr_max;
> +
> + if (nr_oos == nr_next)
> + session->nr_oos_count++;
> + else
> + session->nr_oos_count = 0;
> +
> + session->nr_oos = nr_oos;
> + if (session->nr_oos_count > session->nr_oos_count_max) {
> + session->reorder_skip = 1;
> + l2tp_dbg(session, L2TP_MSG_SEQ,
> + "%s: %d oos packets received. "
> + "Resetting sequence numbers\n",
Same comment about the long message string. Not breaking such
strings facilitates grepping in the kernel for them. In theory,
checkpatch.pl should have complained here, but it might not have
recognized the function. If it complains about long string, just ignore it.
WBR, Sergei
prev parent reply other threads:[~2013-07-02 16:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 10:00 [PATCH 0/3] l2tp: make datapath sequence number handling RFC-compliant James Chapman
2013-07-02 10:00 ` [PATCH 1/3] l2tp: do data sequence number handling in a separate func James Chapman
2013-07-02 16:28 ` Sergei Shtylyov
2013-07-02 10:00 ` [PATCH 2/3] l2tp: make datapath sequence number support RFC-compliant James Chapman
2013-07-02 10:00 ` [PATCH 3/3] l2tp: make datapath resilient to packet loss when sequence numbers enabled James Chapman
2013-07-02 16:32 ` Sergei Shtylyov [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=51D300B8.4030807@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=jchapman@katalix.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 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.