From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BF5EC43381 for ; Mon, 1 Apr 2019 11:31:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F29202084B for ; Mon, 1 Apr 2019 11:31:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726545AbfDALbw (ORCPT ); Mon, 1 Apr 2019 07:31:52 -0400 Received: from charlotte.tuxdriver.com ([70.61.120.58]:39569 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725882AbfDALbv (ORCPT ); Mon, 1 Apr 2019 07:31:51 -0400 Received: from cpe-2606-a000-111b-405a-9816-2c85-c514-8f7a.dyn6.twc.com ([2606:a000:111b:405a:9816:2c85:c514:8f7a] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1hAvAD-0001UD-Jg; Mon, 01 Apr 2019 07:31:44 -0400 Date: Mon, 1 Apr 2019 07:31:10 -0400 From: Neil Horman To: Xin Long Cc: network dev , linux-sctp@vger.kernel.org, Marcelo Ricardo Leitner , davem@davemloft.net, Matteo Croce , Vladis Dronov Subject: Re: [PATCH net-next 0/2] sctp: fully support memory accounting Message-ID: <20190401113110.GA20717@hmswarspite.think-freely.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Mar 31, 2019 at 04:53:45PM +0800, Xin Long wrote: > sctp memory accounting is added in this patchset by using > these kernel APIs on send side: > > - sk_mem_charge() > - sk_mem_uncharge() > - sk_wmem_schedule() > - sk_under_memory_pressure() > - sk_mem_reclaim() > > and these on receive side: > > - sk_mem_charge() > - sk_mem_uncharge() > - sk_rmem_schedule() > - sk_under_memory_pressure() > - sk_mem_reclaim() > > With sctp memory accounting, we can limit the memory allocation by > either sysctl: > > # sysctl -w net.sctp.sctp_mem="10 20 50" > > or cgroup: > > # echo $((8<<14)) > \ > /sys/fs/cgroup/memory/sctp_mem/memory.kmem.tcp.limit_in_bytes > > When the socket is under memory pressure, the send side will block > and wait, while the receive side will renege or drop. > > Xin Long (2): > sctp: implement memory accounting on tx path > sctp: implement memory accounting on rx path > > include/net/sctp/sctp.h | 2 +- > net/sctp/sm_statefuns.c | 6 ++++-- > net/sctp/socket.c | 10 ++++++++-- > net/sctp/ulpevent.c | 19 ++++++++----------- > net/sctp/ulpqueue.c | 3 ++- > 5 files changed, 23 insertions(+), 17 deletions(-) > > -- > 2.1.0 > > I don't have a problem with either of these patches in terms of altering memory accounting, but SCTP has the notion of accounting buffers based on either sockets space or association space (based on the sndbuf_policy and rcvbuf_policy sysctls). This patch eliminates them. I don't see this patch addressing either the removal of that functionality (as the proposed accounting scheme renders those sysctls useless and ignored, which may cause regressions in some environments), nor does it address the possibiliy of one association starving others on the same socket when they share the same socket level accounting. I think you need to look how to address that (either by re-adding the ability to account in either case based on the sysctls, or deprecating eliminating the sysctls and addressing the starvation issue. Best Neil