[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <534ED48A.6040502@redhat.com>
Date: Wed, 16 Apr 2014 21:05:46 +0200
From: Daniel Borkmann <dborkman@...hat.com>
To: Vlad Yasevich <vyasevich@...il.com>
CC: Alexander Sverdlin <alexander.sverdlin@....com>,
ext Dongsheng Song <dongsheng.song@...il.com>,
Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@....com>,
davem@...emloft.net, netdev@...r.kernel.org,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to
reflect real state of the receiver's buffer"
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. ]
> 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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists