[Nokia][sonic-platform] Update Nokia sonic-platform submodule

[snider-nokia]

This fixes https://github.com/Nokia-ION/ndk/issues/16.

Why I did it

1. To support dynamic swapping of module types/speeds (400G/100G/40G)
2. To optimize CMIS ZR optics operation

How I did it

Reinitialize xcvr_api at module removal/insertion time, and also optimize cache for ZR optics.

How to verify it

1. Verify that different (supported) module types can be dynamically swapped (removed/inserted) and that each is properly provisioned by Xcvrd and has its EEPROM information accurately reported in Redis DB (using "show transceiver eeprom") as well as "sfputil show eeprom" direct access.

2. Also verify that Xcvrd initialization and operation with 400G CMIS ZR optics is both efficient and functional.
   ** edit 6/14/23: pushed enhanced caching (full memory map) support and elimination of base class APIs override.

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106
• 202111
• 202205
• 202211

Description for the changelog

Cache tuning for ZR optics and add support for dynamic module type/speed swapping.

[snider-nokia]

@prgeor and/or @mihirpat1, can you review? Thanks.

This PR fixes both issues described at https://github.com/Nokia-ION/ndk/issues/16

[prgeor]

@snider-nokia looks like the Cache design in your platform seems not right as the platform sfp.py needs to override the base class APIs (and future APIs) to work with Cache. Why doesn't the cache implementation work seamlessly for any API?

[snider-nokia]

@snider-nokia looks like the Cache design in your platform seems not right as the platform sfp.py needs to override the base class APIs (and future APIs) to work with Cache. Why doesn't the cache implementation work seamlessly for any API?

This model was used originally to more closely monitor/examine (and tune for) what the underlying optoe bulk driver methods were/are doing. If you'd prefer, the overriding of these methods can be removed.

The cache design should (and does) indeed work properly/seamlessly for any API at present (for any page that is currently cacheable).

I can also add the balance of the specification mapped page space even prior to those pages being referenced by Xcvrd...

[prgeor]

@snider-nokia looks like the Cache design in your platform seems not right as the platform sfp.py needs to override the base class APIs (and future APIs) to work with Cache. Why doesn't the cache implementation work seamlessly for any API?

This model was used originally to more closely monitor/examine (and tune for) what the underlying optoe bulk driver methods were/are doing. If you'd prefer, the overriding of these methods can be removed.

The cache design should (and does) indeed work properly/seamlessly for any API at present (for any page that is currently cacheable).

I can also add the balance of the specification mapped page space even prior to those pages being referenced by Xcvrd...

@snider-nokia can we avoid overriding the base class APIs:-

get_transceiver_info()
get_transceiver_info()
get_transceiver_threshold_info()
get_transceiver_pm()

[snider-nokia]

All set, Prince. Tested and ready for merge.

**Note: These new changes require NDK version 22.9.10. Both this PR and associated NDK PR should be merged to 202205 at the same time. Same paradigm should be applied for merge to 202211 (both at the same time).
Associated NDK (version 22.9.10) PR is here: sonic-net/sonic-buildimage-msft#44

[gechiang]

**Note: These new changes require NDK version 22.9.10. Both this PR and associated NDK PR should be merged to 202205 at the same time. Same paradigm should be applied for merge to 202211 (both at the same time).
Associated NDK (version 22.9.10) PR is here

@snider-nokia , Can you clarify if this dependency can cause existing functionality issue?
Please note that the NDK version 22.9.10 is only in the MSFT repo and not in public master nor in public 202205. Therefore the concern is if there is a dependency, would function be broken if one is to pick up this PR in any public branch without the NDK 22.9.10??

[snider-nokia]

**Note: These new changes require NDK version 22.9.10. Both this PR and associated NDK PR should be merged to 202205 at the same time. Same paradigm should be applied for merge to 202211 (both at the same time).
Associated NDK (version 22.9.10) PR is here

@snider-nokia , Can you clarify if this dependency can cause existing functionality issue? Please note that the NDK version 22.9.10 is only in the MSFT repo and not in public master nor in public 202205. Therefore the concern is if there is a dependency, would function be broken if one is to pick up this PR in any public branch without the NDK 22.9.10??

Yes @gechiang, you cannot use one without the other. The PMON changes contained in this PR must be coupled with NDK version 22.9.10 (PR#44) wherever (to whatever branch) either of the referenced PRs are merged. You will indeed see a functionality issue if both PRs are not merged/built together.

[gechiang]

**Note: These new changes require NDK version 22.9.10. Both this PR and associated NDK PR should be merged to 202205 at the same time. Same paradigm should be applied for merge to 202211 (both at the same time).
Associated NDK (version 22.9.10) PR is here

@snider-nokia , Can you clarify if this dependency can cause existing functionality issue? Please note that the NDK version 22.9.10 is only in the MSFT repo and not in public master nor in public 202205. Therefore the concern is if there is a dependency, would function be broken if one is to pick up this PR in any public branch without the NDK 22.9.10??

Yes @gechiang, you cannot use one without the other. The PMON changes contained in this PR must be coupled with NDK version 22.9.10 (PR#44) wherever (to whatever branch) either of the referenced PRs are merged. You will indeed see a functionality issue if both PRs are not merged/built together.

@snider-nokia , Since we cannot have these separated... I would suggest that we first move this PR to the sonic-buildimage-msft and not attempt to merge into public branches... We should then think about how to make these "dependent PRs" available in a way that they can be both applied in the public community branches...

[mlok-nokia]

@gechiang Per design agreement between MSFT and Nokia, public Master doesn't include NDK module. It means the master image is not applicable to be running on Nokia IXR7250E platform. This PR is Nokia specific sonic-platform submodule. It won't impact another vendor. It is safe to merge to the master branch, then cherry-pick to the 202205. This is the method which both MSFT and Nokia agreed with and has been used since the beginning. Thanks.

[prgeor]

@lguohan @yxieca please help merge

[yxieca]

@mlok-nokia can you confirm that this change has been tested on 202205 branch?

[gechiang]

@gechiang Per design agreement between MSFT and Nokia, public Master doesn't include NDK module. It means the master image is not applicable to be running on Nokia IXR7250E platform. This PR is Nokia specific sonic-platform submodule. It won't impact another vendor. It is safe to merge to the master branch, then cherry-pick to the 202205. This is the method which both MSFT and Nokia agreed with and has been used since the beginning. Thanks.

Got it! Thanks for your clarification. Since this PR is only applicable to IXR7250E platform, it will only impact this platform at which whoever needs to run on this platform should be building from the msft repo which has the NDK module.

[gechiang]

MSFT ADO: 24442945

[mssonicbld]

@snider-nokia PR conflicts with 202211 branch

[mssonicbld]

Cherry-pick PR to 202205: #15710

[mssonicbld]

Cherry-pick PR to 202305: #15873

[gechiang]

@snider-nokia , can you address the cherry-pick conflict for this PR in the 202211 branch?
Please raise a clone of this PR with conflict resolved directly under the 202211 branch.
Thanks!

[snider-nokia]

@snider-nokia , can you address the cherry-pick conflict for this PR in the 202211 branch? Please raise a clone of this PR with conflict resolved directly under the 202211 branch. Thanks!

Sorry @gechiang, it looks like I checked the 202211 inclusion box inadvertently. We have not provided supported for that branch since it was forked. I have checked internally and verified this answer, so I have now unchecked the 202211 inclusion box. Thanks.

[gechiang]

@snider-nokia , Thanks for responding, I will go ahead remove the "Request for 202211 branch" label for this PR.
Does this means any Nokia Chassis support PRs will only be supported in 202205 and 202305 going forward and will not be needed in 202211? In general, whenever we backport a fix, we request it be backported to all the previous "higher" releases. In this case if backport to 202205 was needed, therefore we automatically request to back port to 202211 and 202305.

[snider-nokia]

I will raise this issue for internal discussion here, @gechiang. I don't think we have a current plan to support every branch that would qualify for backport (based on your description), but will verify at this end.