Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flesh out multi-process reconfigurable network functions #1257

Merged
merged 31 commits into from
Dec 14, 2017

Conversation

wingo
Copy link
Contributor

@wingo wingo commented Dec 11, 2017

The multi-process facility is no longer a pair of weird apps; instead now it's a library called lib.ptree (for "process tree"). There is better developer-facing documentation in src/lib/ptree/README.md and more importantly there is example code in src/program/ptree, along with README.md there. @xray7224 and @dpino wdyt?

wingo added 29 commits December 11, 2017 09:42
Previously, release() would always fail.
This is the first step in refactoring the "app.config" mechanism to be
something that's more of a library and less like magical apps.
New file applies scheduling parameters for a data plane.
Also add generic worker.main() export from lib.ptree.worker
* src/lib/ptree/worker.lua: Privatize "Worker".
Store next_time locally in the main() function, and in the selftest, run
the main() function for longer than a single tick.
Allow timers to be cancelled.
Having the multiprocess tree and configuration system be implemented as
apps was a neat hack that re-used the app abstraction as a way to add a
reconfiguration back-channel to a dataplane, but it goes against the
abstraction that the core.app / engine facility should really be
targeted towards the dataplane domain; it's not necessarily a great
generic process composition facility.
This name better matches how users will think of it.  Also add
functionality to set program name to the manager, and bind the manager
to a NUMA node as appropriate.  Unclaim the name as the manager stops.
Do assign CPU affinity even if it has to be on a remote node, but warn.
Warn if no CPUs available.
Use config-leader-socket to avoid breaking existing clients.
Copy link
Contributor

@tsyesika tsyesika left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good 👍 I think it makes more sense as a library than set of apps.

Copy link
Contributor

@dpino dpino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing work. I commented on some nits.


local function fatal (msg)
print(msg)
main.exit(1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps is worth moving this function to core/lib since is currently defined at many places (lwaftr/lwutil.lua, at several modules in program/alarms and ptree.lua).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will make a note of it!

local app_graph = require('core.config')
local engine = require('core.app')

if opts == nil then opts = {} end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also can use the idiom opts = opts or {}, as you like more.

engine.configure(app_graph.new())

-- Now we can exit.
S.exit(0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not main.exit(0)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not know. This comes from follower.lua. I guess you mean os.exit(0) btw. Can fix I guess :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, main.exit() does exist but currently simply calls out to os.exit(). I think the idea was to be prepared for potential cleanup code in the engine?

self.file:write(self.header..'\n')
self.file:flush()
function CSVStatsTimer:start()
local function tick() return self:tick() end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the goal of wrapping the self:tick() call instead of calling self:tick() directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because timer functions are called without any arguments, and here we need to call tick(self).

@wingo
Copy link
Contributor Author

wingo commented Dec 14, 2017

OK as this is merged to lwaftr upstream and wingo-next has the rest of the lwaftr updates, I will pull the trigger here and merge to wingo-next, so that it all goes into v2017.12.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants