-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[Mellanox]Fix the issue when an SFP module is plugged into a QSFP port via QSA #3846
Conversation
read the identifier value first and parsed it. if it isn't recognized it will be parsed as the default type according to SKU dictionary
To be cherry-picked to bmtor, it requires the following PR cherry-picked first: |
@yxieca just a kindly reminder: please take it to bmtor. |
@stephenxs, @nazariig: Should this PR (and #3777) also be cherry-picked into the 201911 branch? Are there any other dependencies or any reasons not to? |
hi @jleveque, I suggest doing so. no dependency on 201911. |
@stephenxs: Thanks. Just to clarify, #3777 is a required dependency, but there are no others, correct? |
Fix the issue when an SFP module is plugged into a QSFP port via an adapter. - How I did it Originally the type of an SFP module is determined according to the SKU dictionary. However, it's possible that as SFP module is plugged into a QSFP port via an adapter. In this case, the EEPROM content will be parsed in the wrong format. To address that we fetch the identifier value of an xSFP module and then get the type by parsing it.
Hi @jleveque , |
@stephenxs: So we should or should not also cherry-pick #3777 into the 201911 branch? |
3777 is already merged into 201911. |
Ah, I've got it now. Thanks! #3777 didn't have any "Request for 201911" or "Included in 201911" labels, so I wasn't aware that it had already had been cherry-picked. I will add the "Included in 201911" label to it now. |
Fix the issue when an SFP module is plugged into a QSFP port via an adapter. - How I did it Originally the type of an SFP module is determined according to the SKU dictionary. However, it's possible that as SFP module is plugged into a QSFP port via an adapter. In this case, the EEPROM content will be parsed in the wrong format. To address that we fetch the identifier value of an xSFP module and then get the type by parsing it.
- What I did
Fix the issue when an SFP module is plugged into a QSFP port via an adapter.
- How I did it
Originally the type of an SFP module is determined according to the SKU dictionary. However, it's possible that as SFP module is plugged into a QSFP port via an adapter. In this case, the EEPROM content will be parsed in the wrong format.
To address that we fetch the identifier value of an xSFP module and then get the type by parsing it.
- How to verify it
Fetch and parse the content of SFP modules and check them.
sfp-type-detect-test.txt
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)