[GeneralDiagnostics]: Reporting change for the attributes not managed by the attribute store #11302
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pullapprove
bot
requested review from
anush-apple,
austinh0,
balducci-apple,
bzbarsky-apple,
carol-apple,
cecille,
chrisdecenzo,
chulspro,
Damian-Nordic,
electrocucaracha,
emargolis,
erjiaqing,
franck-apple,
harimau-qirex,
hawk248,
jelderton,
jepenven-silabs,
jmartinez-silabs,
kghost,
kpschoedel,
LuDuda,
msandstedt,
mspang,
pan-apple,
sagar-apple,
saurabhst and
selissia
pullapprove
bot
requested review from
tcarmelveilleux,
tecimovic,
turon,
vivien-apple,
wbschiller and
woody-apple
|
PR #11302: Size comparison from 12ec702 to d911143 Increases above 0.2%:
Increases (20 builds for efr32, k32w, linux, p6, qpg, telink)
Decreases (1 build for p6)
Full report (20 builds for efr32, k32w, linux, p6, qpg, telink)
|
|
PR #11302: Size comparison from 12ec702 to 0fa30d2 Increases above 0.2%:
Increases (35 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
Decreases (5 builds for mbed, p6)
Full report (37 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
yunhanw-google
approved these changes
Nov 2, 2021
… by the attribute store
|
PR #11302: Size comparison from 05200d6 to c49dc04 Increases above 0.2%:
Increases (35 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
Decreases (5 builds for mbed, p6)
Full report (37 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
woody-apple
approved these changes
Nov 2, 2021
saurabhst
approved these changes
Nov 2, 2021
src/app/clusters/general_diagnostics_server/general_diagnostics_server.cpp
Show resolved
Hide resolved
src/app/clusters/general_diagnostics_server/general_diagnostics_server.cpp
Show resolved
Hide resolved
Comment on lines
+162
to
+166
| if (emberAfEndpointIndexIsEnabled(index)) | ||
| { | ||
| EndpointId endpointId = emberAfEndpointFromIndex(index); | ||
|
|
||
| if (emberAfContainsServer(endpointId, GeneralDiagnostics::Id)) |
There was a problem hiding this comment.
This is a little weird in the sense that we go from index to endpoint id, but the first thing emberAfContainsServer ends up doing is getting the index from the endpoint id, which is all a huge waste of cycles.
We should have a function that takes an endpoint index and cluster id and returns whether that cluster is present on that endpoint....
There was a problem hiding this comment.
We need to get endpointID, it is needed by MatterReportingAttributeChangeCallback
There was a problem hiding this comment.
That's fine. Getting endpoint id from index is cheap. But getting index from id is expensive, and that's what emberAfContainsServer ends up doing.
Hence my suggestion for a variant of emberAfContainsServer that takes an index instead of an endpoint id....
Comment on lines
113
to
+117
| case UpTime::Id: { | ||
| return ReadIfSupported(&PlatformManager::GetUpTime, aEncoder); | ||
| return ReadIfSupported(&DeviceLayer::PlatformManager::GetUpTime, aEncoder); | ||
| } | ||
| case TotalOperationalHours::Id: { | ||
| return ReadIfSupported(&PlatformManager::GetTotalOperationalHours, aEncoder); | ||
| return ReadIfSupported(&DeviceLayer::PlatformManager::GetTotalOperationalHours, aEncoder); |
There was a problem hiding this comment.
We never mark UpTime and TotalOperationalHours dirty. Shouldn't we be doing that? Or at least have a followup tracking it?
There was a problem hiding this comment.
Spec say those two attributes should not be subscribed, and those two attributes should only be read
"A Node interested in the value of the UpTime attribute SHOULD NOT subscribe to value changes but SHOULD perform a single read of the value."
There was a problem hiding this comment.
Should not doesn't mean you can't do it, just that it's not necessarily a great idea.
If someone does subscribe to them, the spec as currently written requires reports to be sent on changes.
Now I think this is silly and we should change the spec, personally, but that needs an SDK feedback spec issue, etc.
There was a problem hiding this comment.
most of attributes in diagnostic clusters suffer the same problem, since the values of some diagnostic clusters are consistently changing. Subscribe to those attributes will flood the reporting
There was a problem hiding this comment.
I don't disagree. I am just pointing out that if we think that our impl now follows the spec we are wrong: it does not. If the spec is requiring things that make no sense to implement, we should be filing spec issues, not just silently ignoring what it says and doing something else.
There was a problem hiding this comment.
Comment on lines
+187
to
+188
| PlatformMgr().SetDelegate(&gDiagnosticDelegate); | ||
| ConnectivityMgr().SetDelegate(&gDiagnosticDelegate); |
There was a problem hiding this comment.
Do these delegate registrations survive CHIP stack restart? They are not documented as to whether they do or not...
There was a problem hiding this comment.
No, it is registered after each start, why it needs to survive over restart?
There was a problem hiding this comment.
It depends on the definition of "start", right? This function depends on being called once per process execution. It will not work right if it's called more than once as things stand. If the CHIP stack is shut down and restarted (e.g. via PlatformManager::Shutdown and then a new InitChipStack, etc), either this function will get called again, in which case the attribute access interface bit will be broken, or it will not be called again, in which case are these delegates going to be set up right?
There was a problem hiding this comment.
MatterGeneralDiagnosticsPluginServerInitCallback should be called only once during the lifetime of per process execution. Do we have the scenario we shut down the CHIP stack and restart the CHIP stack without restarting the process? If there is the case, then "registerAttributeAccessOverride(&gAttrAccess);" will also not get called, we are not registering the handle for these platform attributes.
There was a problem hiding this comment.
MatterGeneralDiagnosticsPluginServerInitCallback should be called only once during the lifetime of per process execution.
That is the intent, I think... It happens to not be true in practice right now; see #11352
Do we have the scenario we shut down the CHIP stack and restart the CHIP stack without restarting the process?
Yes, absolutely.
If there is the case, then "registerAttributeAccessOverride(&gAttrAccess);" will also not get called,
Yes, but shutting down the stack does not unregister attr access overrides, so this part is fine.
But in general, we need to decide what the call frequency guarantees are around these callbacks and then make sure that everything in them is operating correctly given those frequency guarantees. Right now, if we actually change MatterGeneralDiagnosticsPluginServerInitCallback to be once-per-process-lifetime this code would break.
|
Lets move the discussion to #11566 |
PSONALl
pushed a commit
to PSONALl/connectedhomeip
that referenced
this pull request
Dec 3, 2021
… by the attribute store (project-chip#11302)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
What is being fixed? Examples:
Change overview
Reporting change for the attributes not managed by the attribute store in general diagnostic cluster.
The platform delegate callback for NetworkInfo update will be done in a separate PR.
Testing
How was this tested? (at least one bullet point required)