[FC] process FC after apply view #3326
Conversation
|
/azpw run |
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
da85acb
to
ffbd073
Compare
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
ffbd073
to
1536dfb
Compare
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
3 times, most recently
from
97e081f
to
95b1e63
Compare
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
6e1f7d5
to
8dca8ef
Compare
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
2 times, most recently
from
7f0a73e
to
e580645
Compare
|
Putting back delay for 60 sec as we found some cases where oper state update handling is delayed due to FC configuration after APPLY_VIEW |
| m_bufferQueueConfigTable(db, CFG_BUFFER_QUEUE_TABLE_NAME), | ||
| m_bufferPgConfigTable(db, CFG_BUFFER_PG_TABLE_NAME), | ||
| m_deviceMetadataConfigTable(db, CFG_DEVICE_METADATA_TABLE_NAME) | ||
| { | ||
| SWSS_LOG_ENTER(); | ||
| m_delayTimer = new SelectableTimer(timespec{.tv_sec = FLEX_COUNTER_DELAY_SEC, .tv_nsec = 0}); | ||
| if (WarmStart::isWarmStart()) |
There was a problem hiding this comment.
Just to confirm this will also handle fast-reboot.
| SWSS_LOG_ENTER(); | ||
|
|
||
| SWSS_LOG_NOTICE("Processing counters"); | ||
| m_delayTimer->stop(); |
There was a problem hiding this comment.
How about following?
if (!m_delayTimerExpired)
{
m_delayTimer->stop();
m_delayTimerExpired = true;
}
orchagent/flexcounterorch.cpp
Outdated
| @@ -254,6 +258,15 @@ void FlexCounterOrch::doTask(Consumer &consumer) | |||
| } | |||
| } | |||
|
|
|||
| void FlexCounterOrch::doTask(SelectableTimer &timer) | |||
There was a problem hiding this comment.
should we delete the timer here?
| } | ||
| else | ||
| { | ||
| m_delayTimerExpired = true; |
There was a problem hiding this comment.
We used to delay counter polling for all reboot types, and now it turns that counter polling will start right after APPLY_VIEW for cold reboot. Although we don't have a hard requirement for cold reboot time, there is still a question: could you please share some data about how this change would affect cold reboot time?
There was a problem hiding this comment.
Mainly due to VS tests expecting FC counters to appear immediately, which would fail without putting some delays. Therefore I limited this change to fast/warm reboot only. I am looking for a way to not delay counters only for VS, then I can have this delay for all reboot types.
There was a problem hiding this comment.
@stepanblyschak Since the change is limited to warm-reboot now, may I know how much time can be saved in warm-reboot after delaying flex counter?
There was a problem hiding this comment.
@bingwang-ms No time savings, the delay was limited to fast and warm boot already. No delay if FC are present in CONFIG_DB already in cold boot.
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
e580645
to
6d3616b
Compare
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
6d3616b
to
230a48f
Compare
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
230a48f
to
12eea05
Compare
mssonicbld
added
Cherry Pick Conflict_202405
and removed
Cherry Pick Conflict_202405
labels
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
2 times, most recently
from
c9f7b28
to
a6c8679
Compare
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
a6c8679
to
c8e8b41
Compare
stepanblyschak
force-pushed
the
fc-after-apply-view
branch
from
3c3ebbd
to
e2a68ae
Compare
|
@wen587 Can you help review? |
What I did
Simplify approach to delaying counters on warm boot and fast boot. Removed FLEX_COUNTER_DELAY_STATUS_FIELD and instead postpone all FC processing to happen after apply view to not delay data plane configuration.
The CONFIG_DB should not be updated in runtime anymore for counters to be delayed.
Why I did it
To address sonic-net/sonic-buildimage#20302.
How I verified it
Run warm-boot - make sure FC orch runs only after APPLY_VIEW.
Details if related