Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions inc/sainexthopgroup.h
Original file line number Diff line number Diff line change
Expand Up @@ -359,6 +359,19 @@ typedef enum _sai_next_hop_group_attr_t
*/
SAI_NEXT_HOP_GROUP_ATTR_ADMIN_ROLE,

/**
* @brief This attribute indicates the nexthop group members weights
*
* NOS must query this attribute for the support.
* False: All members are with equal cost
* True: Members are configured with unequal cost
*
* @type bool
* @flags CREATE_ONLY
* @default false
*/
SAI_NEXT_HOP_GROUP_ATTR_MEMBERS_WITH_UNEQUAL_WEIGHTS,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JaiOCP, what is the additional benefit of querying this capability?

If NOS is configured to program unequal paths, NOS can directly add those members to the NHG with the required weights, right? I believe we don't need any additional hardware capability/support to handle unequal-cost paths in this case.

Please let me know if I am missing any specific use case where this capability is required.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the legacy implementation, yes.
For newer implementation where there is a dedicated resource for weight NHG vs unweighted NHG, we need to differentiate the NHG during NHG create.
Now you can make an argument that why not a new NHG type instead of a bool. Problem with that approach is that NHG may be of any type with members as wieghted or unweighted. Hence the introduction of a new bool attribute.


Comment thread
JaiOCP marked this conversation as resolved.
/**
* @brief End of attributes
*/
Expand Down
Loading