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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 E4406C3A5A1 for ; Wed, 28 Aug 2019 12:32:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C26C822CED for ; Wed, 28 Aug 2019 12:32:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726382AbfH1McE (ORCPT ); Wed, 28 Aug 2019 08:32:04 -0400 Received: from Chamillionaire.breakpoint.cc ([193.142.43.52]:44432 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726300AbfH1McE (ORCPT ); Wed, 28 Aug 2019 08:32:04 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1i2x7K-0002Zv-3Y; Wed, 28 Aug 2019 14:32:02 +0200 Date: Wed, 28 Aug 2019 14:32:02 +0200 From: Florian Westphal To: Eric Dumazet Cc: Florian Westphal , Eric Dumazet , netdev@vger.kernel.org Subject: Re: multipath tcp MIB counter placement - share with tcp or extra? Message-ID: <20190828123202.GI20113@breakpoint.cc> References: <20190828114321.GG20113@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Eric Dumazet wrote: > > Let me know -- I can go with a separate MIB, its no problem, I just want > > to avoid going down the wrong path. > > There are about 40 counters. > > Space for that will be per netns : num_possible_cpus * 40 * 8 bytes > > The cost of folding all the values will make nstat slower even if MPTCP is not used. Ok, so 'same proc file' would be fine but 'increase pcpu mem cost unconditionally' isn't. > Maybe find a way to not having to fold the MPTCP percpu counters if MPTCP is not loaded ? MPTCP is builtin (bool). However, we might be able to delay allocation until first mptcp socket is requested, I will see if this can be done somehow. Thanks Eric!