Skip to content

Update CMIS diagnostics monitoring HLD with TRANSCEIVER_STATUS_SW table + link event handling changes #1964

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 22, 2025

Conversation

mihirpat1
Copy link
Contributor

@mihirpat1 mihirpat1 commented Apr 15, 2025

Created TRANSCEIVER_STATUS_SW table to store information for the following fields (these fields are being moved from TRANSCEIVER_STATUS table since these fields are required to be stored for every logical port unlike other diagnostic tables which are required only for the primary subport for a breakout port group)

- cmis_state
- status
- error

Also, link event handling related changes were added to the HLD

MSFT ADO - 32312479

@mssonicbld
Copy link
Collaborator

/azp run

Copy link

No pipelines are associated with this pull request.

@mihirpat1 mihirpat1 requested review from prgeor and Copilot April 15, 2025 16:27
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR updates the HLD for CMIS diagnostics monitoring by separating diagnostic tables into hardware and software sections and introducing the TRANSCEIVER_STATUS_SW table for storing software transceiver status data.

  • Renames section 3.3 to explicitly indicate hardware-derived data.
  • Removes software-related fields (cmis_state, status, error) from the hardware table.
  • Adds a new section 3.4 detailing the TRANSCEIVER_STATUS_SW table and its thread-safety considerations.
Comments suppressed due to low confidence (1)

doc/platform_api/CMIS_Diagnostic_Monitoring_Overview_in_SONiC.md:1631

  • Consider removing the extra 'is' for proper grammar: 'This table exists only for C-CMIS transceivers.'
This table is exists only for C-CMIS transceivers.

@mssonicbld
Copy link
Collaborator

/azp run

Copy link

No pipelines are associated with this pull request.

@mihirpat1 mihirpat1 changed the title Update CMIS diagnostics monitoring HLD with TRANSCEIVER_STATUS_SW table Update CMIS diagnostics monitoring HLD with TRANSCEIVER_STATUS_SW table + link event handling changes Apr 17, 2025
@mssonicbld
Copy link
Collaborator

/azp run

Copy link

No pipelines are associated with this pull request.

@prgeor prgeor merged commit 3dbc9d7 into sonic-net:master Apr 22, 2025
1 check passed
mssonicbld added a commit to mssonicbld/sonic-utilities.msft that referenced this pull request Apr 28, 2025
…om TRANSCEIVER_INFO table

<!--
    Please make sure you've read and understood our contributing guidelines:
    https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

    ** Make sure all your commits include a signature generated with `git commit -s` **

    If this is a bug fix, make sure your description includes "closes #xxxx",
    "fixes #xxxx" or "resolves #xxxx" so that GitHub automatically closes the related
    issue when the PR is merged.

    If you are adding/modifying/removing any command or utility script, please also
    make sure to add/modify/remove any unit tests from the tests
    directory as appropriate.

    If you are modifying or removing an existing 'show', 'config' or 'sonic-clear'
    subcommand, or you are adding a new subcommand, please make sure you also
    update the Command Line Reference Guide (doc/Command-Reference.md) to reflect
    your changes.

    Please provide the following information:
-->

#### What I did
xcvrd will now move the `status` field from the TRANSCEIVER_STATUS table to the TRANSCEIVER_STATUS_SW table. This is being done via the below PRs

[Update CMIS diagnostics monitoring HLD with TRANSCEIVER_STATUS_SW table by mihirpat1 · Pull Request #1964 · sonic-net/SONiC](sonic-net/SONiC#1964)
[[xcvrd] Re-organize transceiver DOM and STATUS tables by mihirpat1 · Pull Request #604 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#604)

Therefore, the corresponding CLIs that rely on the TRANSCEIVER_STATUS table for retrieving transceiver presence need to be changed.

However, a more robust method to retrieve transceiver presence is by checking if the TRANSCEIVER_INFO table is present. Thus, the relevant code change will be made to address this.

#### How I did it
The CLI handler now looks at the TRANSCEIVER_INFO table to find transceiver presence

#### How to verify it
No change in output when command is executed after putting the change manaully
```
admin@sonic:~$ show mux grpc mux
Port        Direction    Presence    PeerDirection    ConnectivityState
----------  -----------  ----------  ---------------  -------------------
Ethernet4   unknown      True        unknown          unknown
Ethernet8   unknown      True        unknown          unknown
Ethernet12  unknown      True        unknown          unknown
Ethernet16  unknown      True        unknown          unknown
Ethernet20  unknown      True        unknown          unknown
Ethernet24  unknown      True        unknown          unknown
Ethernet28  unknown      True        unknown          unknown

```

For the case where TRANSCEIVER_INFO table is missing by manually deleteing it for example on Port Ethernet4

```
admin@sonic:~$ redis-cli -n 6 DEL "TRANSCEIVER_INFO|Ethernet4"
(integer) 1
admin@sonic:~$ show mux grpc mux
Port        Direction    Presence    PeerDirection    ConnectivityState
----------  -----------  ----------  ---------------  -------------------
Ethernet4   standby      False       standby          READY
Ethernet8   standby      True        standby          READY

```
#### Previous command output (if the output of a command-line utility has changed)

#### New command output (if the output of a command-line utility has changed)

MSFT ADO - 32337615
mssonicbld added a commit to Azure/sonic-utilities.msft that referenced this pull request Apr 28, 2025
…om TRANSCEIVER_INFO table (#171)

<!--
 Please make sure you've read and understood our contributing guidelines:
 https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

 failure_prs.log skip_prs.log Make sure all your commits include a signature generated with `git commit -s` **

 If this is a bug fix, make sure your description includes "closes #xxxx",
 "fixes #xxxx" or "resolves #xxxx" so that GitHub automatically closes the related
 issue when the PR is merged.

 If you are adding/modifying/removing any command or utility script, please also
 make sure to add/modify/remove any unit tests from the tests
 directory as appropriate.

 If you are modifying or removing an existing 'show', 'config' or 'sonic-clear'
 subcommand, or you are adding a new subcommand, please make sure you also
 update the Command Line Reference Guide (doc/Command-Reference.md) to reflect
 your changes.

 Please provide the following information:
-->

#### What I did
xcvrd will now move the `status` field from the TRANSCEIVER_STATUS table to the TRANSCEIVER_STATUS_SW table. This is being done via the below PRs

[Update CMIS diagnostics monitoring HLD with TRANSCEIVER_STATUS_SW table by mihirpat1 · Pull Request #1964 · sonic-net/SONiC](sonic-net/SONiC#1964)
[[xcvrd] Re-organize transceiver DOM and STATUS tables by mihirpat1 · Pull Request #604 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#604)

Therefore, the corresponding CLIs that rely on the TRANSCEIVER_STATUS table for retrieving transceiver presence need to be changed.

However, a more robust method to retrieve transceiver presence is by checking if the TRANSCEIVER_INFO table is present. Thus, the relevant code change will be made to address this.

#### How I did it
The CLI handler now looks at the TRANSCEIVER_INFO table to find transceiver presence

#### How to verify it
No change in output when command is executed after putting the change manaully
```
admin@sonic:~$ show mux grpc mux
Port Direction Presence PeerDirection ConnectivityState
---------- ----------- ---------- --------------- -------------------
Ethernet4 unknown True unknown unknown
Ethernet8 unknown True unknown unknown
Ethernet12 unknown True unknown unknown
Ethernet16 unknown True unknown unknown
Ethernet20 unknown True unknown unknown
Ethernet24 unknown True unknown unknown
Ethernet28 unknown True unknown unknown

```

For the case where TRANSCEIVER_INFO table is missing by manually deleteing it for example on Port Ethernet4

```
admin@sonic:~$ redis-cli -n 6 DEL "TRANSCEIVER_INFO|Ethernet4"
(integer) 1
admin@sonic:~$ show mux grpc mux
Port Direction Presence PeerDirection ConnectivityState
---------- ----------- ---------- --------------- -------------------
Ethernet4 standby False standby READY
Ethernet8 standby True standby READY

```
#### Previous command output (if the output of a command-line utility has changed)

#### New command output (if the output of a command-line utility has changed)

MSFT ADO - 32337615
mihirpat1 pushed a commit to mihirpat1/sonic-utilities.msft that referenced this pull request Apr 30, 2025
…om TRANSCEIVER_INFO table (Azure#171)

<!--
 Please make sure you've read and understood our contributing guidelines:
 https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

 failure_prs.log skip_prs.log Make sure all your commits include a signature generated with `git commit -s` **

 If this is a bug fix, make sure your description includes "closes #xxxx",
 "fixes #xxxx" or "resolves #xxxx" so that GitHub automatically closes the related
 issue when the PR is merged.

 If you are adding/modifying/removing any command or utility script, please also
 make sure to add/modify/remove any unit tests from the tests
 directory as appropriate.

 If you are modifying or removing an existing 'show', 'config' or 'sonic-clear'
 subcommand, or you are adding a new subcommand, please make sure you also
 update the Command Line Reference Guide (doc/Command-Reference.md) to reflect
 your changes.

 Please provide the following information:
-->

#### What I did
xcvrd will now move the `status` field from the TRANSCEIVER_STATUS table to the TRANSCEIVER_STATUS_SW table. This is being done via the below PRs

[Update CMIS diagnostics monitoring HLD with TRANSCEIVER_STATUS_SW table by mihirpat1 · Pull Request #1964 · sonic-net/SONiC](sonic-net/SONiC#1964)
[[xcvrd] Re-organize transceiver DOM and STATUS tables by mihirpat1 · Pull Request #604 · sonic-net/sonic-platform-daemons](sonic-net/sonic-platform-daemons#604)

Therefore, the corresponding CLIs that rely on the TRANSCEIVER_STATUS table for retrieving transceiver presence need to be changed.

However, a more robust method to retrieve transceiver presence is by checking if the TRANSCEIVER_INFO table is present. Thus, the relevant code change will be made to address this.

#### How I did it
The CLI handler now looks at the TRANSCEIVER_INFO table to find transceiver presence

#### How to verify it
No change in output when command is executed after putting the change manaully
```
admin@sonic:~$ show mux grpc mux
Port Direction Presence PeerDirection ConnectivityState
---------- ----------- ---------- --------------- -------------------
Ethernet4 unknown True unknown unknown
Ethernet8 unknown True unknown unknown
Ethernet12 unknown True unknown unknown
Ethernet16 unknown True unknown unknown
Ethernet20 unknown True unknown unknown
Ethernet24 unknown True unknown unknown
Ethernet28 unknown True unknown unknown

```

For the case where TRANSCEIVER_INFO table is missing by manually deleteing it for example on Port Ethernet4

```
admin@sonic:~$ redis-cli -n 6 DEL "TRANSCEIVER_INFO|Ethernet4"
(integer) 1
admin@sonic:~$ show mux grpc mux
Port Direction Presence PeerDirection ConnectivityState
---------- ----------- ---------- --------------- -------------------
Ethernet4 standby False standby READY
Ethernet8 standby True standby READY

```
#### Previous command output (if the output of a command-line utility has changed)

#### New command output (if the output of a command-line utility has changed)

MSFT ADO - 32337615
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.

3 participants