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

Global instances #150

Closed
cole-barefoot opened this issue Mar 30, 2017 · 12 comments

Comments

@cole-barefoot
Copy link
Contributor

commented Mar 30, 2017

The issue of global instances---i.e. top-level control or parser instantiation---came up at the LDWG meeting on Monday, March 27th, 2017.

The Problem

What should the P4_16 spec say about global instantiation, if anything? Here are some situations to consider.

  1. If a control is instantiated at the top level but (a) not used in another control, and (b) not passed as an argument to a package, then is that instance dead code? Can the control plane install rules to its tables?

  2. If a control or parser is instantiated at the top level and used exactly once in another control or parser, is this equivalent to instantiating it locally in the namespace where it is used, and can the compiler inline it?

  3. If a control or parser is instantiated at the top level, can it be used more than once? Does this differ from how a control or parser instantiated locally (inside another control or parser) can be used?

@jafingerhut

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

Probably a too-basic question: For #2 when you ask "can the compiler inline it?", how does the answer being yes or no matter to anyone but someone implementing the back end of a P4 compiler for a particular target? And does it even matter to them?

@mbudiu-vmw

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

It definitely matters to implementers, but it should not matter to users.
We can bypass this problem for now by forbidding top-level instantiations of controls and parsers.
packages are also a problem: we need main to be toplevel. Perhaps we can forbid any other top-level instantiations of packages besides main.

This is sufficient for the targets that are currently supported. If someone argues that they need the ability to share a control invoked by two other controls, we can add this feature to the language later.

@jnfoster

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

@mbudiu-vmw

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

I don't see how the two are related. Almost all the programs in the testsuite are written in this way (not many call controls, though). These programs look fine.

@jnfoster

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

@mbudiu-vmw

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

No, top-level means really top-level, outside of any control.
So I am proposing to allow:

control c() { ...}
control d() { c() ci; ... }

but disallow

control c() { ...  }
c() c;

The syntactic sugar proposed would work as:

control c() { ... }
control d() { apply { c.apply(); }}

turns into

control c() { ... }
control d() { @name("c") c() c_instance; apply { c_instance.apply(); }}
@jnfoster

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

@mbudiu-vmw

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

I was hoping that we agreed on the second proposal in fact.
Maybe we still can...

@jnfoster

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2017

We can revisit it and maybe the second proposal makes more sense if we want to disallow top-level construction.

However, my recollection from last week was that there was a strong preference for the other alternative....

@mbudiu-vmw

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2017

If you look just at the data-plane, the semantics of instantiations is relatively clear.

The only downside for global instances is that when used inlining cannot always be applied. Both our public back-ends rely on inlining to simplify the program; we would have to fix them to give a nice error message when inlining is not applicable.

The semantics of top-level instantiations may be more interesting from a control-plane point of view. Since we don't yet have a spec for the control-plane API, it is difficult to speculate about the implications there.

By removing global instantiations we bury the problem - a locally-instantiated control or parser can always be inlined.

@jnfoster

This comment has been minimized.

Copy link
Contributor

commented May 8, 2017

Do we need to revisit this issue at the 5/8 meeting? We've now resolved #129 differently.

@jnfoster

This comment has been minimized.

Copy link
Contributor

commented May 10, 2017

Closed by #197

@jnfoster jnfoster closed this May 10, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.