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.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 0DC35C31E40 for ; Tue, 6 Aug 2019 18:03:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D57BD20B1F for ; Tue, 6 Aug 2019 18:03:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="3hJwWYcV" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732239AbfHFSDv (ORCPT ); Tue, 6 Aug 2019 14:03:51 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:38096 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726877AbfHFSDv (ORCPT ); Tue, 6 Aug 2019 14:03:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gFTMaprVsWCgr9Uw9bzdPgJHb9ARiC94eqZBiW4eSVc=; b=3hJwWYcV1ev3cSjzWQU0BfllIo c0F1FYsz9lNNEW84aPfPLdbDLkPq/t8q9EV7adJ5fRB1arSCpe3ygFS0Pa43H3Q0wWm+tXIG+DM8f pYaWeqKRb+aJCdmpS8UGIoSvzO7rQlqH4iftV6+sS2mYgzyOh2wv/L8YE4R0ztLbLqpU=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1hv3oI-0006f8-Md; Tue, 06 Aug 2019 20:03:46 +0200 Date: Tue, 6 Aug 2019 20:03:46 +0200 From: Andrew Lunn To: David Ahern Cc: Jiri Pirko , netdev@vger.kernel.org, davem@davemloft.net, mlxsw@mellanox.com, jakub.kicinski@netronome.com, f.fainelli@gmail.com, vivien.didelot@gmail.com, mkubecek@suse.cz, stephen@networkplumber.org, daniel@iogearbox.net, brouer@redhat.com, eric.dumazet@gmail.com Subject: Re: [RFC] implicit per-namespace devlink instance to set kernel resource limitations Message-ID: <20190806180346.GD17072@lunn.ch> References: <20190806164036.GA2332@nanopsycho.orion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Aug 06, 2019 at 11:38:32AM -0600, David Ahern wrote: > On 8/6/19 10:40 AM, Jiri Pirko wrote: > > Hi all. > > > > I just discussed this with DavidA and I would like to bring this to > > broader audience. David wants to limit kernel resources in network > > namespaces, for example fibs, fib rules, etc. > > > > He claims that devlink api is rich enough to program this limitations > > as it already does for mlxsw hw resources for example. If we have this > > api for hardware, why don't to reuse it for the kernel and it's > > resources too? > > The analogy is that a kernel is 'programmed' just like hardware, it has > resources just like hardware (e.g., memory) and those resources are > limited as well. So the resources consumed by fib entries, rules, > nexthops, etc should be controllable. I expect one question that will come up is why not control groups. That is often used by the rest of the kernel for resource control. But cgroups are mostly about limiting resources for a collection of processes. I don't think that is true for networking resources. The resources we are talking about are orthogonal to processes. Or are there any resources which should be linked to processes? eBPF resources? > > So the proposal is to have some new device, say "kernelnet", that would > > implicitly create per-namespace devlink instance. Maybe kernelns, to make it clear we are talking about namespace resources. Going back to cgroups concept. They are generally hierarchical. Do we need any sort of hierarchy here? Are there some resources we want to set a global limit on, and then a per namespace limit on top of that? We would then need two names, and kernelnet sounds more like the global level? Andrew