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: <20240805133702.0f7f222c@kernel.org>
Date: Mon, 5 Aug 2024 13:37:02 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Donald Hunter <donald.hunter@...il.com>, 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 v3 02/12] netlink: spec: add shaper YAML spec

On Mon, 5 Aug 2024 16:35:29 +0200 Paolo Abeni wrote:
> > Perhaps the API would be better if you had:
> > 
> > - shaper-new
> > - shaper-delete
> > - shaper-get/dump
> > - shaper-set
> > - group-new
> > - group-delete
> > - group-get/dump
> > - group-set
> > 
> > If you went with Jakub's suggestion to give every shaper n x inputs and
> > an output, then you could recombine groups and shapers and just have 4
> > ops. And you could rename 'detached' to 'shaper' so that an attachment
> > is one of port, netdev, queue or shaper.  
> 
> I'm unsure I read the above correctly, and I'm unsure it's in the same 
> direction of Jakub's suggestion. AFACS the above is basically the same 
> interface we proposed in the past iteration and was explicitly nacked 
> from Jakub,

To be clear I was against the low level twiddling APIs, where one has to
separately create a mux/group/scheduler and "move" all its children
under it one by one. (due to the problems it creates with atomic
transitions between configurations).

Having shapers separate from the scheduling hierarchy doesn't seem bad,
tho I haven't gone thru all the considerations in my head.

> Additionally, one of the constraint to be addressed here is allowing to 
> setup/configures all the nodes in a 'group' with a single operation, to 
> deal with H/W limitations. How would the above address such constraint?

FWIW I think the naming is the major source of confusion :(

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ