Dynamic transceiver tuning support

[dgsudharsan]

- What I did
Dynamic transceiver tuning support
- How I did it
Dynamically program pre-emphasis and other settings based on media detected in xcvrd. The various supported media are defined in media_settings.json

- How to verify it
Perform OIR of different media types. Dump the pre-emphasis values from hardware and verify that they got reflected

- Description for the changelog

Support for dynamically programming pre-emphasis

- A picture of a cute animal (not mandatory but encouraged)

The latest UT file is attached
Z9100-SONIC-Preemp-2019-05-20-1.txt

[lguohan]

as comments.

[stevenlu99]

@dgsudharsan
How do we plan to test/debug serdes tuning values?
There are few scenarios I can think about:1

1. during development adn ODM development, we need make sure tuning values in json file is correctly write to DB, this should be covered by media_checker script I think.
2. We need make sure values in DB is properly programmed in ASIC at runtime, especially we can not access live setups.
3. In each release cycle, adding new features and adding new platform/optic module support, we want quick verify that transceiver tuning feature is working properly. If possible better automate this process.

To address above 2 & 3, might I purpose below changes?

1. we can utilize SAI API get_port_attribute to read back tuning values. Question is how and when to trigger it. A typical scenario is that some ports might behave wired or giving CRCs sometime. If this happens, the fist thing we want check would be making sure serdes are tuned properly. We can discuss it.
2. Can we add feature in xcvrd to "fake" unplug a SFP? Basically we can mark one or more SFP(s) are unplugged(even they are still in cages), so that we can simulate OIR without physically do that in the lab. With such "fake unplug" feature, we can automate the testing on testbed with few SFPs very quickly.
   Please let me know how you think and we can discuss offline.

Above suggestions could be another separate pull req base on schedule.

[dgsudharsan]

@dgsudharsan
How do we plan to test/debug serdes tuning values?
There are few scenarios I can think about:1

1. during development adn ODM development, we need make sure tuning values in json file is correctly write to DB, this should be covered by media_checker script I think.
2. We need make sure values in DB is properly programmed in ASIC at runtime, especially we can not access live setups.
3. In each release cycle, adding new features and adding new platform/optic module support, we want quick verify that transceiver tuning feature is working properly. If possible better automate this process.

To address above 2 & 3, might I purpose below changes?

1. we can utilize SAI API get_port_attribute to read back tuning values. Question is how and when to trigger it. A typical scenario is that some ports might behave wired or giving CRCs sometime. If this happens, the fist thing we want check would be making sure serdes are tuned properly. We can discuss it.
2. Can we add feature in xcvrd to "fake" unplug a SFP? Basically we can mark one or more SFP(s) are unplugged(even they are still in cages), so that we can simulate OIR without physically do that in the lab. With such "fake unplug" feature, we can automate the testing on testbed with few SFPs very quickly.
   Please let me know how you think and we can discuss offline.

Above suggestions could be another separate pull req base on schedule.

Hello @stevenlu99 . Thanks for your feedback.
For the test cases can you please check this change sonic-net/sonic-swss@b3bc42d There is a VS test case that simulates the xcvrd mechanism and checks if SAI is getting programmed in ASIC DB.
Lets also have a discussion offline and raise a pull request separately if we come up with mechanisms for simulation and testing

[lguohan]

retest this please

[dgsudharsan]

retest this please

Attaching the test log changes.

[lguohan]

retest this please