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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 4EEA3C10F05 for ; Mon, 1 Apr 2019 07:26:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1E43E214C6 for ; Mon, 1 Apr 2019 07:26:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OiO+dTXe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731958AbfDAH0B (ORCPT ); Mon, 1 Apr 2019 03:26:01 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:54076 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731862AbfDAH0A (ORCPT ); Mon, 1 Apr 2019 03:26:00 -0400 Received: by mail-wm1-f65.google.com with SMTP id q16so9130537wmj.3; Mon, 01 Apr 2019 00:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h81vJctFvi4D7BCUs/xqZJgwVmC5sWztv2WsDobEpKc=; b=OiO+dTXenE3qLSQRXCcH7b++jRgttcjVsVS5ZpLl8vHi1mLj7OY6dzc7XyB10XZunl b6h6zLZAShbzC2CrwLV7n0HYur3LLkPiMGXqLtXKfDMqKVFA5hFV2GEXyFNNPRVI+3it iSoDIwkNXOjzZ8wODxEh22KbvR3jigh+wORkLl2iTuYa5Q0fPvBsTBSDwuuwaM5XYVaB 9KOTW3nI1kyR7VcXM7jE3CPoIroQR/h5FsnvJDOBUtb84o2X2fj9/89cPk+kuRkZv7Xk T1LNng7fHGq/kXky0B1tXQjAPOjkMbhaZsPvGHqIGTWuY7/pascGeiRNVxV2nN6rYu5M cbMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h81vJctFvi4D7BCUs/xqZJgwVmC5sWztv2WsDobEpKc=; b=WlyIcX3qf62G+Uq2fFAc1PGh7qrndBmda7Y9Tp1hqihWmY4UwDcd4YGWP3VjWM0/aq jW8h6PppaPel7q1oMNjVxUohBPClS4CHQvZ5Pwz/VCQQf7W80i+d5DGSxiTaTQg2yCIF m6gKhB+Pdb2xxNZftjfCrb6vyo+tbfvABMHMtpTF49a9OlYwRRZtP9TB+X9RRMTNFgbp +twjeCRbpghFyu1nXqhxqNUfmWhEFnA8oXjTvsBMo7Sltp5sfckcPFVgMd6dr1bBUhlu VNm7Pe9I+Dpgj9V83NDRwgV73d9hlcjTMyGSZIH0hQ2BWYlQaZgjXQYaBKHVpr7NEJPn a8aA== X-Gm-Message-State: APjAAAVZibho0JYKswJFCQb/gUOZOh5mAEZs3zGtJtGv0RS5ocbf8Rf7 MRaHfTkzHA8y5Ml3cbtYt77YSZOTycnaQcdVCQl2eX8s/TU= X-Google-Smtp-Source: APXvYqxb+zbG4SyegiGtRhE0j3dtdCGasZ2wjH+ufWV9aoTbx7GCJtIUjj1KkR7S7ZCLTJPaTkWqeu3gI6RxiYl1pjQ= X-Received: by 2002:a1c:4d10:: with SMTP id o16mr11196083wmh.59.1554103558400; Mon, 01 Apr 2019 00:25:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Xin Long Date: Mon, 1 Apr 2019 15:25:49 +0800 Message-ID: Subject: Re: [PATCH net-next 0/2] sctp: fully support memory accounting To: network dev , linux-sctp@vger.kernel.org Cc: Marcelo Ricardo Leitner , Neil Horman , davem , Matteo Croce , Vladis Dronov Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Mar 31, 2019 at 4:53 PM 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 > Reported-by: Matteo Croce From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xin Long Date: Mon, 01 Apr 2019 07:25:49 +0000 Subject: Re: [PATCH net-next 0/2] sctp: fully support memory accounting Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: network dev , linux-sctp@vger.kernel.org Cc: Marcelo Ricardo Leitner , Neil Horman , davem , Matteo Croce , Vladis Dronov On Sun, Mar 31, 2019 at 4:53 PM 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 > Reported-by: Matteo Croce