Hi Nithin, <snip>...
> > You are missing the shaper_shared_(packet, byte)_mode supported for > non-leaf and leaf nodes in struct rte_tm_level_capabilities. > > > > The description of this nodes should be aligned with the description of e.g. > shaper_shared_n_max field: basically, we want to say that, when true, the > flag signifies there is at least on non-leaf/leaf node on this level that can > be > part of a shared shaper that works in packet/byte mode. Makes sense? > > I intentionally didn't add shaper_shared_(packet, byte)_mode in node and > level > capabilities and added it in only global cap assuming existing semantics are > enforcing that. > > Currently, except for 'shaper_shared_n_max', all the other existing shared > shaper capabilities like > shaper_shared_dual_rate_n_max, shaper_shared_rate_min, etc are only > provided in global cap. > > I felt the semantics are as such because, shared shaper doesn't really belong > to any node > or level and any node from any level can attach to a particular shared shaper. > Isn't it so > ? That's exactly why we need to formulate node/level capability from node's perspective, and not from the shared shaper's perspective, as a shared shaper is by definition related to a set of nodes, not just one node. The fact that a given node can be part of a shared shaper that works in packet or byte mode, etc is a node capability in itself, right? So the node's capability called "shaper_shared_(packet, byte)_mode" being supported by the node means that this specific node can be part of a shared shaper that has those properties. To me, this is a valuable thing to capture in node/level capabilities. We already have other node level capabilities for shared shaper, and we apply the same rationale there. What do you think? Regards, Cristian
