Postpone intf task after buffer configuration applied on the port. #539
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This also ensures all port setting applied before intf setting.
Signed-off-by: Jipan Yang [email protected]
What I did
Don't apply intf setting on a port before buffer applied on the port.
The order of orches in m_orchList guaranteed that for pending tasks, buffer is processed before port, port before intf.
Why I did it
There is racing condition that, even when "PortInitDone" has been received and m_initDone set true, buffer configuration hasn't been applied.
https://github.com/Azure/sonic-swss/blob/dcf6c905410f08b004e880dbed56823d29e7bd5e/orchagent/portsorch.cpp#L1360
mtu setting for port will be postponed, while IntfsOrch::doTask() only checks gPortsOrch->isInitDone(). For router interface creation, it uses default port mtu which may be different from the one to be configured.
Seen with VS, potentially also may happen on hardware box.
swss.rec, check Ethernet4
Also syslog:
How I verified it
VS testing.
Details if related