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]

Message-ID: <e683f849274f95ce99607e79cba21111997454f9.camel@redhat.com>
Date: Tue, 02 Jul 2024 16:21:38 +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 Mon, 2024-07-01 at 19:54 -0700, Jakub Kicinski wrote:
> On Mon, 01 Jul 2024 12:14:32 +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_?
> 
> I see, I had a look at patch 2 now.
> But that's really "Andrew's use-case" it doesn't cover deletion, right?
> Sorry that I don't have a perfect suggestion either but it seems like
> a half-measure. It's a partial support for transactions. If we want
> transactions we should group ops like nftables. Have normal ops (add,
> delete, modify) and control ops (start, commit) which clone the entire
> tree, then ops change it, and commit presents new tree to the device.

Yes, it does not cover deletion _and_ update/add/move within the same
atomic operation.

Still any configuration could be reached from default/initial state
with set(<possibly many shapers>). Additionally, given any arbitrary
configuration, the default/initial state could be restored with a
single delete(<possibly many handlers>).

The above covers any possible limitation enforced by the H/W, not just
the DSA use-case.

Do you have a strong feeling for atomic transactions from any arbitrary
state towards any other? If so, I’d like to understand why?

Dealing with transactions allowing arbitrary any state <> any state
atomic changes will involve some complex logic that seems better
assigned to user-space.

Thanks,

Paolo