[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20120903.132444.1801063740284928920.davem@davemloft.net>
Date: Mon, 03 Sep 2012 13:24:44 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: vyasevich@...il.com
Cc: tgraf@...g.ch, linux-sctp@...r.kernel.org, netdev@...r.kernel.org,
vyasevic@...hat.com, nhorman@...driver.com
Subject: Re: [PATCH] sctp: Don't charge for data in sndbuf again when
transmitting packet
From: Vlad Yasevich <vyasevich@...il.com>
Date: Mon, 3 Sep 2012 11:02:51 -0400
>
>
> On Sep 3, 2012, at 10:27 AM, Thomas Graf <tgraf@...g.ch> wrote:
>
>> SCTP charges wmem_alloc via sctp_set_owner_w() in sctp_sendmsg() and
>> via
>> skb_set_owner_w() in sctp_packet_transmit(). If a sender runs out of
>> sndbuf it will sleep in sctp_wait_for_sndbuf() and expects to be waken
>> up
>> by __sctp_write_space().
>>
>> Buffer space charged via sctp_set_owner_w() is released in
>> sctp_wfree()
>> which calls __sctp_write_space() directly.
>>
>> Buffer space charged via skb_set_owner_w() is released via
>> sock_wfree()
>> which calls sk->sk_write_space() _if_ SOCK_USE_WRITE_QUEUE is not set.
>> sctp_endpoint_init() sets SOCK_USE_WRITE_QUEUE on all sockets.
>>
>> Therefore if sctp_packet_transmit() manages to queue up more than
>> sndbuf
>> bytes, sctp_wait_for_sndbuf() will never be woken up again unless it
>> is
>> interrupted by a signal.
>>
>> This could be fixed by clearing the SOCK_USE_WRITE_QUEUE flag but ...
>>
>> Charging for the data twice does not make sense in the first place, it
>> leads to overcharging sndbuf by a factor 2. Therefore this patch only
>> charges a single byte in wmem_alloc when transmitting an SCTP packet
>> to
>> ensure that the socket stays alive until the packet has been released.
>>
>> This means that control chunks are no longer accounted for in
>> wmem_alloc
>> which I believe is not a problem as skb->truesize will typically lead
>> to overcharging anyway and thus compensates for any control overhead.
>
> Acked-by: Vlad Yasevich <vyasevich@...il.com>
Applied and queued up for -stable, thanks everyone.
--
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