[P4-design] global instances

Gordon Brebner Gordon.Brebner at xilinx.com
Tue May 9 12:16:17 EDT 2017

+1 for (2).


From: P4-design [mailto:p4-design-bounces at lists.p4.org] On Behalf Of Dan Talayco
Sent: Tuesday, May 09, 2017 7:18 AM
To: Nate Foster <jnfoster at cs.cornell.edu>
Cc: p4-design at lists.p4.org
Subject: Re: [P4-design] global instances

> (2) Forbid top-level global state.

+1 for (2) (though I can see arguments for supporting it). (2) is more inline with P4 historically. I think it can be a fairly easy extension of the language if there is a desire to support it in the future for particular targets.

On Tue, May 9, 2017 at 12:20 AM, Nate Foster <jnfoster at cs.cornell.edu<mailto:jnfoster at cs.cornell.edu>> wrote:
Dear P4 Designers,

I take my job as a professor seriously including, too often, being quite absent minded. Issues #150 (https://github.com/p4lang/p4-spec/issues/150) was supposed to be on the agenda for this afternoon's meeting, but I somehow neglected to include it. My apologies.

Since this issue was already discussed at a previous language design working group meeting and we are in the home stretch for finalizing P4_16, I'd like to propose that we attempt to resolve it by email if possible.

The issue concerns global instances -- i.e., can one declare a variable outside of the scope of any P4-programmable component as in the following program?

bit<32> x;
control c1() { ... x = 0; ... }
control c2() { ... x = x + 1; }

Arguments for:

- The abstraction of top-level global variables may be more convenient and more familiar to programmers.

- In cases where a top-level global variable is used just once, the compiler can inline those variables anyway.

Arguments against:

- Not all targets will be able to implement programs where a top-level global variable is accessed by multiple P4-programmable components.

- Arguably it's more in the spirit of P4-16 if all global state resides in the architecture.

- Being conservative would suggest removing top-level global instances in the short term, and adding them back if we decide they are useful later. The opposite is harder to do.

Possible decisions:

(1) Stick with the status quo and allow top-level global state.

(2) Forbid top-level global state.

(3) Allow top-level global state only if it can be inlined.

I could personally live with any of these options. However, I have a preference for (2) in the short-term since it seems safest.

Please let me know what you think about this issue, either publicly, or privately if you prefer...


P4-design mailing list
P4-design at lists.p4.org<mailto:P4-design at lists.p4.org>

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20170509/31a3e8ec/attachment-0002.html>

More information about the P4-design mailing list