Network Socket Statistics

[deepikabhavnani]

Description

This is the initial version of stats implementation in network layer.
SocketStats Class is added to collect and provide the statistics information. In this phase only socket information is collected and max sockets that can be recorded at any time are configurable through 'MBED_CONF_NSAPI_SOCKET_STATS_MAX_COUNT'

Network statistics can be enabled through a macro MBED_NW_STATS_ENABLED

More information on design is captured in #8743

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[X] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

[deepikabhavnani]

CC @SeppoTakalo @lauri-piikivi @sg- @SenRamakri

[adbridge]

@deepikabhavnani, thank you for your changes. A review has been requested from the following:
@ARMmbed/mbed-os-core @ARMmbed/mbed-os-ipcore

[SeppoTakalo]

I cannot approve this design.

This is way too far away from what current Mbed OS statistics APIs are.

Only usable thing in this PR is the stack_stats_t which contains packet counters.

If that is what have been requested, then we should have designed API similar to existing statistics APIS.

For example:

/** Network statistics */
typedef struct {
    uint32_t pkt_xmit;         /**< Transmitted packets. */
    uint32_t pkt_recv;         /**< Received packets. */
    uint16_t sock_open;        /**< Number of sockets opened */
} network_stats_t;
/** Get the network statistics */
void mbed_stats_network_get(network_stats_t *stats);

This would match the existing mbed_stats.h API.

I cannot understand why network statics have been done so overly complex way.

If the example proposal I just show is fine, it should have been asked from IP networking team to implement. If more complex statistics have been asked, then I'm not aware of the requirements and we should have started by creating a design that can be justified by the requirements document.

[deepikabhavnani]

If the example proposal I just show is fine, it should have been asked from IP networking team to implement. If more complex statistics have been asked, then I'm not aware of the requirements and we should have started by creating a design that can be justified by the requirements document.

This is not the right forum to discuss this, but I would leave a comment stating design was shared nearly 3 months ago and numerous meetings request were made to discuss that as well

[cmonr]

@deepikabhavnani This needs a rebase.

[deepikabhavnani]

@SeppoTakalo @lauri-piikivi @SenRamakri - Please review

[deepikabhavnani]

@ARMmbed/mbed-os-maintainers - Travis astyle failures related to trailing spaces, there is no clear indication for user that error is because of extra space.

-     *                  If the number of sockets on the system is less than or equal to count, 
+     *                  If the number of sockets on the system is less than or equal to count,

[cmonr]

PR updated. Restarting CI.

[cmonr]

@deepikabhavnani Looks like there are still unittest issues.

[deepikabhavnani]

@cmonr - Fixed now.. Was able to test on linux machine

[cmonr]

Thanks @deepikabhavnani. CI restarted.

[deepikabhavnani]

@ARMmbed/mbed-os-maintainers - Please have a look

Stopped the test run stuck from 4 hours.

<1s
/builds/ws/mbed-os-ci_mbed2-build-GCC_ARM@2/749/XADOW_M0_GCC_ARM_749@tmp/durable-ae8d361d: No space left on device

[deepikabhavnani]

/builds/ws/mbed-os-ci_mbed2-build-IAR/746/USENSE_IAR_746@tmp/durable-44ce7b4b: No space left on device

[cmonr]

Restarted jobs with failed results.

Somehow, other jobs seem to not have been hit with the disk storage issue. Fingers crossed.

[mbed-ci]

Test run: SUCCESS

Summary: 4 of 4 test jobs passed
Build number : 14
Build artifacts
Build logs