Add option to make Nanostack use global event queue #7107

kjbracey · 2018-06-04T14:35:03Z

Description

As a potential memory saving, offer the option to let Nanostack run its event loop in the global event queue context.

Pull request type

[ ] Fix
[ ] Refactor
[ ] New target
[X] Feature
[ ] Breaking change

Could arguably be a "fix" for the increased memory usage of 5.9.0. for mini client.

kjbracey · 2018-06-04T14:57:54Z

@TeroJaasko - untested, but do you think this would work for you? Should just need to switch your big stack allocation to the global event queue, along with setting it to "dispatch from from main", and then do so.

SeppoTakalo · 2018-06-07T10:40:43Z

This needs lot of testing before I would turn this option on, hoever, if off by default, its safer to go in and enter longer testing runs.

0xc0170 · 2018-06-11T12:03:55Z

features/nanostack/nanostack-hal-mbed-cmsis-rtos/ns_event_loop_mbed.cpp

@@ -0,0 +1,86 @@
+/*
+ * Copyright (c) 2016 ARM Limited, All Rights Reserved


shouldn't these new files have licenses as the rest of t he files (apache) ?

JanneKiiskila · 2018-06-13T11:24:02Z

Which release could this make?

cmonr · 2018-06-19T00:53:21Z

@JanneKiiskila This is an interesting PR. It can definitely be seen as a fix as @kjbracey-arm mentioned, however it could also be seen as a new feature, because it's adding new functionality that wasn't previously there. If this is deemed closer to a feature than a fix, it will be released in 5.10.

I'm more inclined to lean towards a fix, since this particular changeset appears to not require users to change their applications. @ARMmbed/mbed-os-maintainers thoughts?

By the way, the new files still need full license headers.

0xc0170 · 2018-06-20T12:32:16Z

Based on the changes and feedback above (about having it off and testing it for longer), I would use minor version for this one. However as noted, if there is an issue that this is addressing, considering patch would be fine.

@JanneKiiskila @kjbracey-arm please advise

I would like to run CI, but waiting for the license fix

cmonr · 2018-06-25T15:29:45Z

@kjbracey-arm @JanneKiiskila Any update on the PR?

TeroJaasko · 2018-06-29T17:12:47Z

Looks good to me. This works on my K64F & ESP8266. Tested after rebasing with current Mbed OS master. Verified also with the MBED_CONF_EVENTS_SHARED_DISPATCH_FROM_APPLICATION option.

One could even modify eventOS_scheduler_run() to have

#if defined(MBED_CONF_NANOSTACK_HAL_EVENT_LOOP_USE_MBED_EVENTS) && defined(MBED_CONF_EVENTS_SHARED_DISPATCH_FROM_APPLICATION)
    EventQueue *queue = mbed::mbed_event_queue();
    queue->dispatch_forever();
#else
<original code>
#endif

so this would be a drop in replacement and one could select the underlying event dispatching model by mbed_app.json. But that might be too evil.

This still creates larger code than Mbed OS 5.8, where one could get event based application with networking stack running in a single thread (ie. from main() function) without most of RTOS code for semaphore and threads. If the high priority event queue could also be optionally dispatched from the application thread, the amount of RTOS primitives and RAM usage could be minimized.

cmonr · 2018-06-30T01:29:35Z

@JanneKiiskila @kjbracey-arm please advise

I would like to run CI, but waiting for the license fix

kjbracey · 2018-07-02T09:20:42Z

Inserted Apache licence

0xc0170 · 2018-07-02T09:45:01Z

features/nanostack/nanostack-hal-mbed-cmsis-rtos/ns_event_loop_mutex.c

@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2016 ARM Limited, All Rights Reserved


These 2 files are still not having the proper license (+header file)

0xc0170 · 2018-07-02T09:45:12Z

features/nanostack/nanostack-hal-mbed-cmsis-rtos/ns_event_loop_mutex.h

+extern "C" {
+#endif
+
+void ns_event_loop_mutex_init(void);


Should this have doxygen doc (I noticed a comment in the code file, can be moved here)

Don't think so - it's internal API. Only exists because of a split between two C files here.

Ultimately gets called a couple of layers down inside public APIs that do have Doxygen (ns_hal_init for Nanostack HAL-using apps like mbed client, else the constructor of a Nanostack-based NetworkInterface).

We could use /internal and still move that comment here. Not certain if this is our practice (I searched platform/drivers for internal keyword, not found it in the docs) but would encourage that.

@ARMmbed/mbed-docs documentation for internal functions? we have doxygen internal flag set to NO so will be excluded. No internal flag mention in https://docs.mbed.com/docs/mbed-os-api-reference/en/latest/APIs/API_Documentation/

0xc0170 · 2018-07-02T09:45:38Z

features/nanostack/nanostack-hal-mbed-cmsis-rtos/ns_event_loop_mutex.c

+ * Copyright (c) 2016 ARM Limited, All Rights Reserved
+ */
+
+#include <mbed_assert.h>


why assert is having <> for inclusion?

0xc0170 · 2018-07-02T10:19:15Z

features/nanostack/nanostack-hal-mbed-cmsis-rtos/ns_event_loop.c

@@ -2,18 +2,20 @@
 * Copyright (c) 2016 ARM Limited, All Rights Reserved


As we are changing this file, also license should fixed (can we make sure have proper license headers in nanostack) ?

kjbracey · 2018-07-02T10:57:48Z

Popped in some \internal Doxy

simosillankorva

Seems to work fine, at least when both events.shared-dispatch-from-application and nanostack-hal.event-loop-use-mbed-events are enabled.

JanneKiiskila · 2018-07-11T13:06:44Z

I want this to a patch release, we can't wait for 5.10 with this one.

0xc0170 · 2018-07-11T13:54:20Z

I want this to a patch release, we can't wait for 5.10 with this one.

This adds a new functionality, can't be part of the patch release unfortunately.

0xc0170 · 2018-07-11T13:54:30Z

/morph build

bulislaw · 2018-07-11T14:15:19Z

It's not a new feature really. It's changing the internals of how nanostack works to fix an issue with the size of the system. I don't see a reason why that wouldn't go into a patch release.

JanneKiiskila · 2018-07-11T14:24:30Z

Thank @bulislaw , I agree 100% with you.

adbridge · 2018-07-11T14:26:02Z

@bulislaw @JanneKiiskila
I think the main question is:
Does this add a new api that can be used by a developer? If the answer is yes then it is a new feature and should go to a feature release, irrespective of whether or not it has been added with backwards compatibility. We have mechanisms in place for allowing the development of code in a more controlled environment other than 'master' between feature releases, it's called using a feature branch. However if the changes are purely internal and there is no new public facing API then it can go to a patch release.

bulislaw · 2018-07-11T14:28:14Z

No it doesn't, it changes internals of Nanostack and exposes a config option so that MCC can tweak it.

adbridge · 2018-07-11T14:35:06Z

So anyone can use this option and tweak the configuration, potentially breaking something ? Sounds like a change in behaviour of the code which is also only supposed to go to feature releases. It is a very grey area.
Normally where there are instances like this our position is as follows:
The submitter or other authorized person makes their case for inclusion in a patch release directly to @ChiefBureaucraticOfficer citing any project impact etc and then he can make the decision.

bulislaw · 2018-07-11T14:43:25Z

Any change can break things, even bug fix can break something so I don't think that's specific to features.

On the side note @kjbracey-arm @JanneKiiskila why do we give people choice? It's just more configuration to support and tests, could we only support the shared event queue?

0xc0170 · 2018-07-11T15:00:33Z

I made my comment without realizing my earlier comment:

Based on the changes and feedback above (about having it off and testing it for longer), I would use minor version for this one. However as noted, if there is an issue that this is addressing, considering patch would be fine.

👍

ghost · 2018-07-11T15:16:40Z

I am generally inclined to approve, but could you clarify one item? Does it change functionality for existing projects? i.e. if I have designed a product already and update to this patch, will I have to change any code for compatibility?

mbed-ci · 2018-07-11T15:43:55Z

Build : SUCCESS

Build number : 2570
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7107/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

bulislaw · 2018-07-11T16:05:34Z

@ChiefBureaucraticOfficer no, you won't need to change anything for cases that used to work. This change adds an optimisation that can be switched on to save some memory.

Before we merge that we should understand why do we need to have this choice and not just use the optimised version.

cmonr · 2018-07-11T16:23:44Z

Marking DNM for the time being to make sure this doesn't get merged without @bulislaw question is asnwered.

mbed-ci · 2018-07-11T17:22:31Z

Exporter Build : SUCCESS

Build number : 2214
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7107/

mbed-ci · 2018-07-11T20:10:24Z

Test : SUCCESS

Build number : 2324
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7107/2324

ghost · 2018-07-12T13:13:22Z

Ok, based on bulislav's comments above, I see no reason to hold up this PR any further. Lets move forward with integration.

bulislaw · 2018-07-12T13:37:45Z

From internal discussion:

The changes may have impact on memory pressure in the system and also utilisation of main scheduling queue, therefore they shouldn't be make default in patch release.

That makes sense to me, we should proceed with merging that with patch release tag.

Add option to make Nanostack use global event queue

kjbracey requested review from SeppoTakalo and TeroJaasko June 4, 2018 14:35

0xc0170 added the needs: review label Jun 4, 2018

kjbracey force-pushed the ns-global-events branch from fa38e8e to 31e46fd Compare June 5, 2018 07:30

SeppoTakalo previously approved these changes Jun 7, 2018

View reviewed changes

0xc0170 reviewed Jun 11, 2018

View reviewed changes

cmonr added needs: work and removed needs: review labels Jun 20, 2018

TeroJaasko previously approved these changes Jun 29, 2018

View reviewed changes

cmonr added needs: CI needs: work and removed needs: work needs: CI labels Jun 30, 2018

kjbracey dismissed stale reviews from TeroJaasko and SeppoTakalo via 898ca13 July 2, 2018 09:19

kjbracey force-pushed the ns-global-events branch from 31e46fd to 898ca13 Compare July 2, 2018 09:19

0xc0170 requested changes Jul 2, 2018

View reviewed changes

kjbracey force-pushed the ns-global-events branch from 898ca13 to a25fba3 Compare July 2, 2018 10:04

0xc0170 reviewed Jul 2, 2018

View reviewed changes

kjbracey force-pushed the ns-global-events branch from f73d1b9 to e8ceedd Compare July 2, 2018 10:57

simosillankorva approved these changes Jul 11, 2018

View reviewed changes

0xc0170 approved these changes Jul 11, 2018

View reviewed changes

0xc0170 added needs: CI release-version: 5.9.3 and removed needs: review labels Jul 11, 2018

cmonr added the do not merge label Jul 11, 2018

cmonr added ready for merge and removed do not merge needs: CI labels Jul 12, 2018

cmonr merged commit 6800215 into ARMmbed:master Jul 12, 2018

0xc0170 removed the ready for merge label Jul 12, 2018

pan- pushed a commit to pan-/mbed that referenced this pull request Aug 22, 2018

Merge pull request ARMmbed#7107 from kjbracey-arm/ns-global-events

b702598

Add option to make Nanostack use global event queue

		@@ -0,0 +1,86 @@
		/*
		* Copyright (c) 2016 ARM Limited, All Rights Reserved

		@@ -0,0 +1,58 @@
		/*
		* Copyright (c) 2016 ARM Limited, All Rights Reserved

		@@ -2,18 +2,20 @@
		* Copyright (c) 2016 ARM Limited, All Rights Reserved

Add option to make Nanostack use global event queue #7107

Add option to make Nanostack use global event queue #7107

Uh oh!

Conversation

kjbracey commented Jun 4, 2018

Description

Pull request type

Uh oh!

kjbracey commented Jun 4, 2018

Uh oh!

SeppoTakalo commented Jun 7, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JanneKiiskila commented Jun 13, 2018

Uh oh!

cmonr commented Jun 19, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xc0170 commented Jun 20, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cmonr commented Jun 25, 2018

Uh oh!

TeroJaasko commented Jun 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cmonr commented Jun 30, 2018

Uh oh!

kjbracey commented Jul 2, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 Jul 2, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kjbracey commented Jul 2, 2018

Uh oh!

simosillankorva left a comment

Choose a reason for hiding this comment

Uh oh!

JanneKiiskila commented Jul 11, 2018

Uh oh!

0xc0170 commented Jul 11, 2018

Uh oh!

0xc0170 commented Jul 11, 2018

Uh oh!

bulislaw commented Jul 11, 2018

Uh oh!

JanneKiiskila commented Jul 11, 2018

Uh oh!

adbridge commented Jul 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bulislaw commented Jul 11, 2018

Uh oh!

adbridge commented Jul 11, 2018

Uh oh!

bulislaw commented Jul 11, 2018

Uh oh!

0xc0170 commented Jul 11, 2018

Uh oh!

ghost commented Jul 11, 2018

Uh oh!

mbed-ci commented Jul 11, 2018

Triggering tests

Uh oh!

bulislaw commented Jul 11, 2018

Uh oh!

cmonr commented Jul 11, 2018

Uh oh!

cmonr commented Jun 19, 2018 •

edited

Loading

0xc0170 commented Jun 20, 2018 •

edited

Loading

TeroJaasko commented Jun 29, 2018 •

edited

Loading

0xc0170 Jul 2, 2018 •

edited

Loading

adbridge commented Jul 11, 2018 •

edited

Loading