On Sat, Feb 23, 2019 at 09:58:57PM -0500, David Ahern wrote: > On 2/23/19 6:25 PM, Alexei Starovoitov wrote: > >>> hmm. please see our NRM presentation at LPC. > > Reference? > > We also gave a talk about a resource manager in November 2017: > > https://netdevconf.org/2.2/papers/roulin-hardwareresourcesmgmt-talk.pdf > > in this case the context is hardware resources for networking which > aligns with devlink and switchdev. > > >>> It is a networking _resource_ management for cgroups. > >>> Bandwidth enforcement is a particular example. > >>> It's not a policer either. > >>> > >> > >> Well, this definitely looks a policer to me, sorry if we disagree, this is > >> fine. > > > > this particular example certainly does look like it. we both agree. > > It's overall direction of this work that is aiming to do > > network resource management. For example bpf prog may choose > > to react on SLA violations in one cgroup by throttling flows > > in the other cgroup. Aggregated per-cgroup bandwidth doesn't > > need to cross a threshold for bpf prog to take action. > > It could do 'work conserving' 'policer'. > > I think this set of patches represent a revolutionary approach and existing > > networking nomenclature doesn't have precise words to describe it :) > > 'NRM' describes our goals the best. > > Are you doing something beyond bandwidth usage? e.g., are you limiting > neighbor entries, fdb entries or FIB entries by cgroup? what about > router interfaces or vlans? I cannot imagine why or how you would manage > that but my point is the meaning of 'network resources'.
'network resources' also include back bone and TOR capacity and this mechanism is going to help address that as well.
