-
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
[BFN] Updated platform plugins #9540
Conversation
This pull request introduces 6 alerts when merging f79c084 into d05afb5 - view on LGTM.com new alerts:
|
This pull request introduces 6 alerts when merging 13714d2 into d05afb5 - view on LGTM.com new alerts:
|
This pull request introduces 6 alerts when merging 8e1c743 into d05afb5 - view on LGTM.com new alerts:
|
35cc487
to
6a9c4b8
Compare
This pull request introduces 3 alerts when merging 6a9c4b8c8509b6539d280a4d79d57f6cb1988e9c into f3df6e2 - view on LGTM.com new alerts:
|
6a9c4b8
to
07cf78f
Compare
This pull request introduces 1 alert when merging 07cf78f33b76551b17a69c7e284ddb230ea06b1b into 36673c1 - view on LGTM.com new alerts:
|
8062eec
to
373e7d2
Compare
This pull request introduces 1 alert when merging 373e7d282e7bfa3c266a450f1e5be48f9626fcf2 into 36673c1 - view on LGTM.com new alerts:
|
False negative, same as reported here: github/codeql#3617 |
57dd4ac
to
61dfb02
Compare
This pull request introduces 1 alert when merging 61dfb02 into a6d0a27 - view on LGTM.com new alerts:
|
@lguohan , please approve and merge |
@sujinmkang , please approve and merge. Thank you |
This pull request introduces 1 alert when merging 1d8832d into 67e40b5 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 8dfbbff11e535c25f49da61bb087a6184cf49fad into 3aec728 - view on LGTM.com new alerts:
|
Signed-off-by: Andriy Kokhan <[email protected]>
Signed-off-by: Andriy Kokhan <[email protected]>
Signed-off-by: Volodymyr Boyko <[email protected]>
…_eval() issue Signed-off-by: Andriy Kokhan <[email protected]>
* Signed-off-by: Vadym Yashchenko <[email protected]>
81e125a
to
b1aa104
Compare
This pull request introduces 2 alerts when merging b1aa104 into 3aec728 - view on LGTM.com new alerts:
|
bd55b30
to
83751fe
Compare
….literal_eval() issue" This reverts commit 1e73127.
…ult config generation Signed-off-by: Andriy Kokhan <[email protected]>
This pull request introduces 2 alerts when merging 83751fe into 48a648c - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 8b734dc into 36d8660 - view on LGTM.com new alerts:
|
@lguohan , please approve and merge. |
QSFP_TYPE = "QSFP" | ||
QSFP_DD_TYPE = "QSFP_DD" | ||
|
||
|
||
class SfpUtil(SfpUtilBase): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use Sfp refactoring because SFP handling in SONiC has moved to mostly platform independent code. Ref: SFP refactoring HLD.
Use SfpOptoeBase class instead of SfpUtilBase (which is going to be phased out)
Example Dell platform moved to using SFP refactored code : - #9016
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@prgeor , thank you for reviewing. Totally make sense. Looks like redesigning into sonic_xcvr approach and testing will take some time. Can we have these changes merged as-is (mainly because of other components) and refactor SFP part in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sonic_xcvr is already tested so your platform is good to use sonic_xcvr approach. There is very little code that is platform specific when it comes to supporting the transceivers, so very less platform specific code means less testing and bugs for your platform. please let me know if you face any issue while moving to sonic_xcvr.
Signed-off-by: Andriy Kokhan <[email protected]>
This pull request introduces 1 alert when merging a06129c into 8bb9ed6 - view on LGTM.com new alerts:
|
return self.SFP_STATUS_UNPLUGGED | ||
return self.SFP_STATUS_OK | ||
|
||
def tx_disable(self, tx_disable): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tx_disable is not platform specific. Why override? its already available here https://github.com/Azure/sonic-platform-common/blob/master/sonic_platform_base/sonic_xcvr/api/public/sff8436.py#L227
return self.tx_disable_channel(0xF, tx_disable) | ||
return False | ||
|
||
def tx_disable_channel(self, channel, disable): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not platform specific. why override this?
_, pwr_override = pltfm_mgr_try(get_qsfp_power_override) | ||
return pwr_override | ||
|
||
def set_power_override(self, power_override, power_set): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
already implemented here https://github.com/Azure/sonic-platform-common/blob/master/sonic_platform_base/sonic_xcvr/api/public/sff8436.py#L253 why override here?
def set_lpmode(self, lpmode): | ||
with Sfp.sfputil.eeprom_action() as u: | ||
return u.set_low_power_mode(self.port_num, lpmode) | ||
def write_eeprom(self, offset, num_bytes, write_buffer): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if not overriding, can this be removed?
@prgeor , thank you for reviewing the changes. As you can see, in this SFP plugin we expose SFP eeprom content through the file cache which is updated each time |
In future when your platform needs to support QSFP-DD then your platform will have to duplicate the code in sonic_xcvr. Currently Xcvrd only collects DOM related info from transceiver, but in future QSFP-DD module will need initialization which has data path link synchronization requirement see ref. sonic-net/SONiC#916. Xcvrd is platform independent and won't support any platform specific requirement and hence its important for platform to re-use sonic_xcvr which is compliant with various MSA specifications. |
@prgeor , thank you for the detailed explanation. I really appreciate this. We will plan and adjust SFP plugin implementation accordingly. |
Signed-off-by: Andriy Kokhan [email protected]
Co-authored-by: KostiantynYarovyiBf [email protected]
Co-authored-by: Vadym Yashchenko [email protected]
Co-authored-by: Dmytro Lytvynenko [email protected]
Co-authored-by: Volodymyr Boiko [email protected]
Co-authored-by: Petro Bratash [email protected]
Why I did it
Added missing implementation for BFN platform APIs
How I did it
How to verify it
Run sonic-mgmt platform TCs
Which release branch to backport (provide reason below if selected)
Description for the changelog
Depends on #9564