-
Notifications
You must be signed in to change notification settings - Fork 172
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
Read ID register for optoe1 to find pageable bit in optoe driver #308
Conversation
Signed-off-by: Mihir Patel <[email protected]>
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.
Your change looks good to me.
The only comment I might have is that the comment doesn't easily convey that this change only applies to QSFP w/ CMIS and not SFP w/ CMIS.
A mention of the SFF-8024 spec
could be useful to explain where the magic ID values come from.
Addressed this now. |
@mihirpat1 can you update the test result for performance issue for reading additional bytes? |
@donboll, could you please review the series? |
I have updated the test summary for the same now. |
@StormLiangMS please cherry pick to 202211 |
* Fixes for emmc unreliability (#270) * Read ID register to find pageable bit in optoe driver Signed-off-by: Mihir Patel <[email protected]> * Modified comment in code to make it QSFP specific * Changed QSFP+ to QSFP28 in comment * Added performance stats related to EEPROM read --------- Signed-off-by: Mihir Patel <[email protected]> Co-authored-by: Samuel Angebault <[email protected]> Co-authored-by: Prince George <[email protected]>
Update sonic-linux-kernel submodule pointer to include the following: * 6847319 Read ID register for optoe1 to find pageable bit in optoe driver ([sonic-net#308](sonic-net/sonic-linux-kernel#308)) * 42ad073 Add markers to faciliate easy parsing of kconfig-inclusion and series ([sonic-net#309](sonic-net/sonic-linux-kernel#309)) Signed-off-by: Vivek Reddy <[email protected]>
Sorry for the delay in replying. I am in the silicon valley, or power was knocked out all week.
I’ve reviewed the change, it looks simple and effective, it should work.
A couple of notes, regarding the performance impact…
No significant time difference is seen related to EEPROM read after adding the current changes. Below stats were taken for a 100G CMIS based
transceiver with making it as optoe3 v/s optoe1
Test stats (average time taken after 3 dumps)
Time to dump first 4096B from EEPROM with transceiver as optoe3 - 914ms
Time to dump first 4096B from EEPROM with transceiver as optoe1 - 911ms
If this test was done as a single 4K read, then there was only one read of the ID byte, which would be small compared to the full 4K read. The impacted case is short reads of pages beyond page 0. For CMIS devices, page 11 might be read often to check the “Channel state, flags and monitors”. This is where we find all the alarms and warnings, per channel, for things like TxLOS, Tx CDR LOL, Tx Power High/Low, Tx Bias Current High/Low, etc. This page might be typically read regularly by health monitoring software, for every device in the switch. Try running 100 reads of page 11 (EEPROM bytes 1536-1663) to see if the overhead is higher.
Note that there should also be a performance impact on QSFP (non-CMIS) devices. These will also fall into the case that reads the ID register. Keep in mind that with the patch, optoe3 devices do not suffer the performance impact, so it is appropriate to compare optoe3 vs optoe1 CMIS device performance. QSFP (non-CMIS) devices will always be impacted by this patch, so the only way to compare performance for true optoe1 devices is between the patched and unpatched drivers. However… For QSFP (non-CMIS) devices, there is not much interesting data beyond page 0. For reads between offset 0 and offset 255, the page checking does not happen. So there is no performance penalty (CMIS or non_CMIS) for data in the first 256 bytes. Bottom Line: In the real world, there should be VERY little accesses beyond byte 255 on QSFP (non-CMIS) devices, so the performance impact on those devices doesn’t really matter. Don’t bother measuring it.
So… I would like to see the optoe3 vs optoe1 performance impact on a large number of small reads of page 11, rather than on a single read of a large block.
Don
From: Paul Menzel ***@***.***
Sent: Monday, March 13, 2023 2:10 PM
To: sonic-net/sonic-linux-kernel ***@***.***>
Cc: donboll ***@***.***>; Mention ***@***.***>
Subject: Re: [sonic-net/sonic-linux-kernel] Read ID register for optoe1 to find pageable bit in optoe driver (PR #308)
@donboll <https://github.com/donboll> , could you please review the series?
—
Reply to this email directly, view it on GitHub <#308 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6VCJ4ZDUV2PAX3CQAFQETW36EKHANCNFSM6AAAAAAVW7OKEQ> .
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Update sonic-linux-kernel submodule pointer to include the following: * 6847319 Read ID register for optoe1 to find pageable bit in optoe driver ([#308](sonic-net/sonic-linux-kernel#308)) * 42ad073 Add markers to faciliate easy parsing of kconfig-inclusion and series ([#309](sonic-net/sonic-linux-kernel#309)) Signed-off-by: Vivek Reddy <[email protected]>
* Fixes for emmc unreliability (#270) * Read ID register to find pageable bit in optoe driver Signed-off-by: Mihir Patel <[email protected]> * Modified comment in code to make it QSFP specific * Changed QSFP+ to QSFP28 in comment * Added performance stats related to EEPROM read --------- Signed-off-by: Mihir Patel <[email protected]> Co-authored-by: Samuel Angebault <[email protected]> Co-authored-by: Prince George <[email protected]>
The current optoe driver looks at bit 2 for all optoe1
(dev_class as ONE_ADDR) transceivers to detect if it's pageable or not.
However, for 100G CMIS based transceivers, some platforms use it as optoe1
and not optoe3. With CMIS, the pageable bit has now changed to bit 7 for
the same register. This causes incorrect behavior when the driver checks
for pageability on 100G CMIS transceiver and hence, we need to
read the transceiver ID to see if the transceiver is CMIS based and then
find the relevant pageable bit.
Test result
Tested the changes on a switch with a 100G CMIS and non-CMIS transceiver
Signed-off-by: Mihir Patel [email protected]