[dpdk-dev] [PATCH v2 1/4] ethdev: add tm support for shaper config in pkt mode

[Dumitrescu, Cristian]

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