Skip to content

HLD: Front Panel Port LED Policy - #2223

Open
justin-oliver wants to merge 1 commit into
sonic-net:masterfrom
justin-oliver:master-led-policy
Open

HLD: Front Panel Port LED Policy#2223
justin-oliver wants to merge 1 commit into
sonic-net:masterfrom
justin-oliver:master-led-policy

Conversation

@justin-oliver

Copy link
Copy Markdown

Add a HLD describing a new policy for front panel LEDs. This proposal defines consistent behavior for port LEDs and moves the LED state/color logic out of the platform layer and into LEDD daemon. The proposal covers breakout scenarios and how to map subports to 1 or more port LEDs.

@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

Copy link
Copy Markdown
No pipelines are associated with this pull request.

Comment thread doc/pmon/port-led-policy.md Outdated
Signed-off-by: Justin Oliver <justinoliver@arista.com>
@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

Copy link
Copy Markdown
No pipelines are associated with this pull request.

@pfallon-nexthop pfallon-nexthop left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Thanks Justin! I just had a question for the policy when it comes to adaptors.


A front panel port will have 0 to N LEDs associated with it. The LED policy will evenly split the logical interfaces of a front panel port across the available LEDs. If the number of LEDs exceeds the number of logical interfaces, the extra LEDs will remain off.

For example, an OSFP port with 2 LEDs:

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Can you please clarify what would be the behavior for an OSFP port with 2 LEDs if a QSFP Adaptor is inserted?

In this case there would only be 4 usable lanes. Based on the stated policy, I would expect the two LEDs to split the interfaces on the first 4 lanes between them. However, this means the physical lanes the LED pertains to for status will change with an adaptor, which could add some complexity and may be confusing.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Hi Paul! The current plan is to distribute the usable lanes across the LEDs. As you pointed out, the mapping will be somewhat dynamic when adaptors are used but I hope the new CLI command makes it very clear which lanes map to which LEDs.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Thanks Justin! That seems reasonable to me. I think it would be helpful to add one example along these lines.

@aaronpayment
aaronpayment requested a review from judyjoseph April 1, 2026 21:42
@bingwang-ms

Copy link
Copy Markdown
Contributor

@judyjoseph Can you help review?

@justin-oliver

Copy link
Copy Markdown
Author

I've create sonic-net/sonic-platform-common#662 which has the platform API changes to support the new policy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants