netdev - Re: [PATCH net-next 1/5] netlink: spec: add shaper YAML spec

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]

Date: Mon, 01 Jul 2024 12:14:32 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>, Madhu Chittim
 <madhu.chittim@...el.com>, Sridhar Samudrala <sridhar.samudrala@...el.com>,
  Simon Horman <horms@...nel.org>, John Fastabend
 <john.fastabend@...il.com>, Sunil Kovvuri Goutham <sgoutham@...vell.com>,
 Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH net-next 1/5] netlink: spec: add shaper YAML spec

On Fri, 2024-06-28 at 19:12 -0700, Jakub Kicinski wrote:
> On Thu, 27 Jun 2024 22:17:18 +0200 Paolo Abeni wrote:
> 
> > +      -
> > +        name: shapers
> > +        type: nest
> > +        multi-attr: true
> > +        nested-attributes: ns-info
> 
> How do shapers differ from shaping attrs in this scope? :S

the set() operation must configure multiple shapers with a single
command - to allow the 'atomic configuration changes' need for Andrew's
use-case.

Out-of-sheer ignorance on my side, the above was the most straight-
forward way to provide set() with an array of shapers.

Do you mean there are better way to achieve the goal, or "just" that
the documentation here is missing and _necessary_?

> > +operations:
> > +  list:
> > +    -
> > +      name: get
> > +      doc: |
> > +        Get / Dump information about a/all the shaper for a given device
> > +      attribute-set: net_shaper
> > +      flags: [ admin-perm ]
> 
> Any reason why get is admin-perm ?

Mostly a "better safe then sorry" approach and cargo-cult form other
recent yaml changes the hard reasons. Fine to drop it, if there is
agreement.

Side note: ack to everything else noted in your reply.

Thanks,

Paolo