netdev - Re: [RFC] implicit per-namespace devlink instance to set kernel resource limitations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190806190637.GE17072@lunn.ch>
Date:   Tue, 6 Aug 2019 21:06:37 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, dsahern@...il.com,
        netdev@...r.kernel.org, davem@...emloft.net, mlxsw@...lanox.com,
        f.fainelli@...il.com, vivien.didelot@...il.com, mkubecek@...e.cz,
        stephen@...workplumber.org, daniel@...earbox.net,
        brouer@...hat.com, eric.dumazet@...il.com
Subject: Re: [RFC] implicit per-namespace devlink instance to set kernel
 resource limitations

On Tue, Aug 06, 2019 at 11:54:49AM -0700, Jakub Kicinski wrote:
> On Tue, 6 Aug 2019 20:38:41 +0200, Jiri Pirko wrote:
> > >> So the proposal is to have some new device, say "kernelnet", that
> > >> would implicitly create per-namespace devlink instance. This devlink
> > >> instance would be used to setup resource limits. Like:
> > >> 
> > >> devlink resource set kernelnet path /IPv4/fib size 96
> > >> devlink -N ns1name resource set kernelnet path /IPv6/fib size 100
> > >> devlink -N ns2name resource set kernelnet path /IPv4/fib-rules size 8
> > >> 
> > >> To me it sounds a bit odd for kernel namespace to act as a device, but
> > >> thinking about it more, it makes sense. Probably better than to define
> > >> a new api. User would use the same tool to work with kernel and hw.
> > >> 
> > >> Also we can implement other devlink functionality, like dpipe.
> > >> User would then have visibility of network pipeline, tables,
> > >> utilization, etc. It is related to the resources too.
> > >> 
> > >> What do you think?  
> > >
> > >I'm no expert here but seems counter intuitive that device tables would
> > >be aware of namespaces in the first place. Are we not reinventing
> > >cgroup controllers based on a device API? IMHO from a perspective of
> > >someone unfamiliar with routing offload this seems backwards :)  
> > 
> > Can we use cgroup for fib and other limitations instead?
> 
> Not sure the question is to me, I don't feel particularly qualified,
> I've never worked with VDCs or wrote a switch driver.. But I'd see
> cgroups as a natural fit, and if I read Andrew's reply right so does
> he.. 

Hi Jakub

I think there needs to be a clearly reasoned argument why cgroups is
the wrong answer to this problem. I myself don't know enough to give
that answer, but i can pose the question.

     Andrew