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,URIBL_BLOCKED,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 ACD8AC4360F for ; Tue, 2 Apr 2019 11:41:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 840E820856 for ; Tue, 2 Apr 2019 11:41:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730553AbfDBLl4 (ORCPT ); Tue, 2 Apr 2019 07:41:56 -0400 Received: from charlotte.tuxdriver.com ([70.61.120.58]:53373 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726716AbfDBLl4 (ORCPT ); Tue, 2 Apr 2019 07:41:56 -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 1hBHnb-0004VK-Ab; Tue, 02 Apr 2019 07:41:53 -0400 Date: Tue, 2 Apr 2019 07:41:23 -0400 From: Neil Horman To: Marcelo Ricardo Leitner Cc: Xin Long , network dev , linux-sctp@vger.kernel.org, davem@davemloft.net, Matteo Croce , Vladis Dronov Subject: Re: [PATCH net-next 0/2] sctp: fully support memory accounting Message-ID: <20190402114123.GB17593@hmswarspite.think-freely.org> References: <20190401113110.GA20717@hmswarspite.think-freely.org> <20190402033610.GO16876@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190402033610.GO16876@localhost.localdomain> 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 Tue, Apr 02, 2019 at 12:36:10AM -0300, Marcelo Ricardo Leitner wrote: > On Mon, Apr 01, 2019 at 07:31:10AM -0400, Neil Horman wrote: > > 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. > > That's not how I'm reading these. All original conditions are still > there while these patches are adding a couple of restrictions more. > What that means is that they are adding a ceiling to it, even if the > limits are per socket or per assoc. Considering the idea of the cgroup > limit being added here, it makes sense to me. If the cgroup is > configured to allow at most X MB, it doesn't matter how that is > allocated. That's a sysadmin task then, to adjust the other sysctls > (net.sctp.sctp_mem & cia) and balance the usage, be it per socket or > per asoc. > You're right, I had the sense on the conditional backwards in my head. My bad Series Acked-by: Neil Horman