netdev - Re: [PATCH v3 02/12] 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: <ZrrxZnsTRw2WPEsU@nanopsycho.orion>
Date: Tue, 13 Aug 2024 07:38:46 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>,
	Donald Hunter <donald.hunter@...il.com>, netdev@...r.kernel.org,
	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

Mon, Aug 12, 2024 at 07:42:21PM CEST, kuba@...nel.org wrote:
>On Mon, 12 Aug 2024 18:50:06 +0200 Jiri Pirko wrote:
>> Mon, Aug 12, 2024 at 05:25:44PM CEST, kuba@...nel.org wrote:
>> >I think the confusion is primarily about the parent / child.
>> >input and output should be very clear, IMO.  
>> 
>> For me, "inputs" and "output" in this context sounds very odd. It should
>> be children and parent, isn't it. Confused...
>
>Parent / child is completely confusing. Let's not.
>
>User will classify traffic based on 'leaf' attributes.
>Therefore in my mind traffic enters the tree at the "leaves", 
>and travels towards the root (whether or not that's how HW 
>evaluates the hierarchy).
>
>This is opposite to how trees as an data structure are normally
>traversed. Hence I find the tree analogy to be imperfect.

Normally? Tree as a datastructure could be traversed freely, why it
can't? In this case, it is traversed from leaf to root. It's still a
tree. Why the tree analogy is imperfect. From what I see, it fits 100%.


>But yes, root and leaf are definitely better than parent / child.

Node has 0-n children and 0-1 parents. In case it has 0 children, it's a
leaf, in case it has 0 parents, it's a root.
This is the common tree terminology, isn't it?


>
>> >> Also while at it, I think renaming the 'group()' operation as 
>> >> 'node_set()' could be clearer (or at least less unclear), WDYT?  
>> >
>> >No idea how we arrived at node_set(), and how it can possibly   
>> 
>> subtree_set() ?
>
>The operation is grouping inputs and creating a scheduler node.

Creating a node inside a tree, isn't it? Therefore subtree.

But it could be unified to node_set() as Paolo suggested. That would
work for any node, including leaf, tree, non-existent internal node.


>
>> >represent a grouping operation.
>> >The operations is grouping inputs and creating a scheduler node.
>> >  
>> >> Note: I think it's would be more user-friendly to keep a single 
>> >> delete/get/dump operation for 'nodes' and leaves.  
>> >
>> >Are you implying that nodes and leaves are different types of objects?
>> >Aren't leaves nodes without any inputs?  
>> 
>> Agree. Same op would be nice for both.