On 6 Aug 2019, at 12:06, Andrew Lunn wrote:

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

For the example above, the first question would be why is the restriction based on the number of entries instead of their memory footprint? The resource
being consumed is memory, so I'd think that should be what is monitored.

Quickly scanning the cgroups documentation, it seems there is a device controller, so this isn't just process based. ISTR that Larry Brakmo was working on a network
bandwidth limiter, which is controlled by cgroups.
--
Jonathan



Reply via email to