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: <ZzykxEIYZPjjRbVy@nanopsycho.orion>
Date: Tue, 19 Nov 2024 15:46:28 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Carolina Jubran <cjubran@...dia.com>, Tariq Toukan <tariqt@...dia.com>,
	"David S. Miller" <davem@...emloft.net>,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, netdev@...r.kernel.org,
	Saeed Mahameed <saeedm@...dia.com>, Gal Pressman <gal@...dia.com>,
	Leon Romanovsky <leonro@...dia.com>,
	Cosmin Ratiu <cratiu@...dia.com>, donald.hunter@...il.com
Subject: Re: [PATCH net-next V3 3/8] devlink: Extend devlink rate API with
 traffic classes bandwidth management

Tue, Nov 19, 2024 at 03:33:13PM CET, kuba@...nel.org wrote:
>On Tue, 19 Nov 2024 10:31:03 +0100 Jiri Pirko wrote:
>> >It seems that type: indexed-array with sub-type: u32 would be the correct
>> >approach. However, I noticed that this support appears to be missing in the
>> >ynl-gen-c.py script in this series:
>> >https://lore.kernel.org/all/20240404063114.1221532-3-liuhangbin@gmail.com/.
>> >If this is indeed the case, how should I specify the min and max values for
>> >the u32 entries in the indexed-array?  
>> 
>> Not sure. Perhaps Jakub/Donald would know. Ccing.
>
>I haven't read full context, but all "nested" arrays are discouraged.
>Use:
>	multi-attr: true
>and repeat the entries without wrapping them into another attr.

But we need to use the array index. It looks a bit odd to me to depent
on the index in multi-attr in general. It is not guaranteed other
atrributes don't get in the middle. Ordering should be maintained, that
is ok.

How about to have a nest that contain just one multi-attr attribute?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ