From: Vlad Yasevich <vyasevich@gmail.com>
To: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>,
ext Daniel Borkmann <dborkman@redhat.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>,
ext Dongsheng Song <dongsheng.song@gmail.com>,
davem@davemloft.net, netdev@vger.kernel.org,
"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>
Subject: Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
Date: Wed, 16 Apr 2014 15:47:53 -0400 [thread overview]
Message-ID: <534EDE69.8090404@gmail.com> (raw)
In-Reply-To: <534ED8DF.8040808@nsn.com>
On 04/16/2014 03:24 PM, Matija Glavinic Pecotic wrote:
> On 04/16/2014 09:05 PM, ext Daniel Borkmann wrote:
>> On 04/16/2014 08:50 PM, Vlad Yasevich wrote:
>>> On 04/16/2014 05:02 AM, Alexander Sverdlin wrote:
>>>> Hi Dongsheng!
>>>>
>>>> On 16/04/14 10:39, ext Dongsheng Song wrote:
>>>>> >From my testing, netperf throughput from 600 Mbit/s drop to 6 Mbit/s,
>>>>> the penalty is 99 %.
>>>>
>>>> The question was, do you see this as a problem of the new rwnd algorithm?
>>>> If yes, how exactly?
>>
>> [ Default config ./test_timetolive from lksctp-test suite triggered
>> that as well actually it appears, i.e. showing that the app never
>> woke up from the 3 sec timeout. ]
>
> We had a different case there. Test wasnt hanging due to decreased performance, but due to fact that with the patch sender created very large message, as opposed to situation before the patch where test message was of much smaller size.
>
> http://www.spinics.net/lists/linux-sctp/msg03185.html
The problem with the test is that it tries to completely fill the
receive window by using a single SCTP message. This all goes well
and the test expects a 0-rwnd to be advertised.
The test then consumes said message. At this point, the test expects
the window to be opened and subsequent messages be sent or timed-out.
This doesn't happen, because the window update is not sent. So
the sender thinks that the window is closed which it technically is
since we never actually update asoc->rwnd. But the receive buffer
is empty since we drained the data.
We have a stuck association.
Hard to do when traffic is always flowing one way or the other, but
in a test, it's easy.
-vlad
>
>>> The algorithm isn't wrong, but the implementation appears to have
>>> a bug with window update SACKs. The problem is that
>>> sk->sk_rmem_alloc is updated by the skb destructor when
>>> skb is freed. This happens after we call sctp_assoc_rwnd_update()
>>> which tries to send the update SACK. As a result, in default
>>> config with per-socket accounting, the test
>>> if ((asoc->base.sk->sk_rcvbuf - rx_count) > 0)
>>> uses the wrong values for rx_count and results in advertisement
>>> of decreased rwnd instead of what is really available.
next prev parent reply other threads:[~2014-04-16 19:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 19:45 [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Daniel Borkmann
2014-04-14 19:57 ` Vlad Yasevich
2014-04-16 6:57 ` Matija Glavinic Pecotic
2014-04-16 8:39 ` Dongsheng Song
2014-04-16 9:02 ` Alexander Sverdlin
2014-04-16 11:55 ` Matija Glavinic Pecotic
2014-04-16 13:32 ` Vlad Yasevich
2014-04-16 18:50 ` Vlad Yasevich
2014-04-16 19:05 ` Daniel Borkmann
2014-04-16 19:24 ` Matija Glavinic Pecotic
2014-04-16 19:47 ` Vlad Yasevich [this message]
2014-04-21 19:12 ` Matija Glavinic Pecotic
2014-04-14 20:48 ` David Miller
2014-04-15 8:46 ` Alexander Sverdlin
2014-04-15 8:57 ` Daniel Borkmann
2014-04-15 6:43 ` Alexander Sverdlin
2014-04-15 7:08 ` Daniel Borkmann
2014-04-15 14:27 ` Butler, Peter
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=534EDE69.8090404@gmail.com \
--to=vyasevich@gmail.com \
--cc=alexander.sverdlin@nsn.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=dongsheng.song@gmail.com \
--cc=linux-sctp@vger.kernel.org \
--cc=matija.glavinic-pecotic.ext@nsn.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).