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

Implement support for non-const table entries #3748

Merged
merged 12 commits into from
Jun 7, 2023
Merged

Conversation

mihaibudiu
Copy link
Contributor

Signed-off-by: Mihai Budiu mbudiu@vmware.com

This validates the design in p4lang/p4-spec#1180

@mihaibudiu
Copy link
Contributor Author

This implementation does not have the code to generate the priorities yet, but validates the grammar

@mihaibudiu
Copy link
Contributor Author

there are a bunch of failures due to the inability to install the software in CI.
I don't understand the bazel complaints:

ERROR: /home/runner/work/p4c/p4c/BUILD.bazel:180:11: Compiling frontends/common/constantFolding.cpp failed: undeclared inclusion(s) in rule '//:ir_frontend_midend_control_plane':
this rule is missing dependency declarations for the following files included by 'frontends/common/constantFolding.cpp':
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/stddef.h'
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/stdarg.h'

I haven't touched this file.

@mihaibudiu
Copy link
Contributor Author

@smolkaj any clues why bazel is unhappy?

@smolkaj
Copy link
Member

smolkaj commented Dec 1, 2022

This is the error message:

ERROR: /home/runner/work/p4c/p4c/BUILD.bazel:180:11: Compiling frontends/common/constantFolding.cpp failed: undeclared inclusion(s) in rule '//:ir_frontend_midend_control_plane':
this rule is missing dependency declarations for the following files included by 'frontends/common/constantFolding.cpp':
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/stddef.h'
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/stdarg.h'
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/stdint.h'
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/limits.h'
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/syslimits.h'
  '/usr/lib/gcc/x86_64-linux-gnu/11/include/float.h'
...

Did you make any changes to frontends/common/constantFolding.cpp? Not as far as I can tell?

@mihaibudiu
Copy link
Contributor Author

I didn't that's why I find this puzzling.

@mihaibudiu
Copy link
Contributor Author

@smolkaj
Copy link
Member

smolkaj commented Dec 1, 2022

@smolkaj
Copy link
Member

smolkaj commented Dec 2, 2022

I tried on my laptop and couldn't reproduce the issue. So could indeed be a caching issue. If we can't figure out how to clear the cache, here are some random things we might try...:

  • add a .bazelrc with the following contents to the root of the repo:
    # Use C++17.
    build: --cxxopt=-std=c++17 --host_cxxopt=-std=c++17
    
  • replace ubuntu-latest with ubuntu-22.04 in ci-bazel.yml

EDIT: An easy workaround that will clear the cache: in ci-bazel.yml, replace

        key: ${{ runner.os }}-build-direct-${{ github.sha }}

with something like

        key: bazel-${{ runner.os }}-build-direct-${{ github.sha }}

@fruffy
Copy link
Collaborator

fruffy commented Dec 2, 2022

I cleared the cache. Looks like it is fixed.

}

control c(in Headers h) {
action a() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

It would be good if those actions have some effect on outputs to test the compiler passes.

@mihaibudiu
Copy link
Contributor Author

@jafingerhut can you please review this?

@mihaibudiu
Copy link
Contributor Author

@jafingerhut this now uses the syntax with mandatory 'priority' and a colon after the priority

@mihaibudiu
Copy link
Contributor Author

If we settle on this syntax I will implement the additional features in the spec PR, e.g., priority assignment.

@mihaibudiu
Copy link
Contributor Author

@jafingerhut the last commit is meant to implement the spec completely with regards to non-const entries

@jafingerhut
Copy link
Contributor

@mihaibudiu Thanks! I will try to review at least the test cases, and perhaps parts of the implementation regarding generation of warnings, soon-ish.

@mihaibudiu
Copy link
Contributor Author

I have tested the warning generation too, but was too lazy to add the tests.

@jafingerhut
Copy link
Contributor

@mihaibudiu Fortunately adding test cases and checking their outputs is my p4c specialty! :-)

@jnfoster
Copy link
Contributor

jnfoster commented May 19, 2023 via email

@jafingerhut
Copy link
Contributor

jafingerhut commented May 20, 2023

Thanks for this implementation. I noticed that it is a bit different in the way it assigns priorities to entries than the language spec proposes.

The spec says that if some priorities are explicitly given by the P4 developer in the source code, but not all, that

(1) the first entry must have a priority explicitly specified.
(2) pseudocode in the spec explains how all other entry priorities are determined, from earliest entries in the source to the last entry in the source.

This PR as of commit 4 has a different implementation, where if largest_priority_wins is true, it assigns priorities from last entry in the source back to the first.

I think it would be good for the spec and implementation to match in how priorities are assigned to entries. Either we should review a PR that updates the spec to match this implementation, or we should make this implementation match the spec. My personal preference would be to change this implementation to match the spec.

@jafingerhut
Copy link
Contributor

jafingerhut commented May 20, 2023

Another thing that would be good to have: in the code that determines the entry priorities, save the results of the determined priority values in such a way that the control plane API generation code can read and output those priority values.

I understand that if you want to emit P4_16 source code from the IR after the priorities are determined, in such a way that only the entries that the P4 developer explicitly specified priority values will have them in that printed P4_16 source code later, you would need a way in the IR to remember which entries have priority values from the source code, versus which ones have priority values determined by the compiler.

But another alternative is to explicitly choose that the P4_16 code emitted from the IR does have explicit priority values for every entry. I cannot think of any harm if we do that. Not only would there be no harm, but it would be a way to verify that the compiler-determined priority values were correct, by diff'ing them against the priority values in the -frontend.p4 and/or -midend.p4 files output by the compiler, and compared against files stored in this repo.

CHECK_NULL(table);
auto ep = table->properties->getProperty(IR::TableProperties::entriesPropertyName);
CHECK_NULL(ep);
if (ep->isConstant) return entries;
Copy link
Contributor

@jafingerhut jafingerhut May 20, 2023

Choose a reason for hiding this comment

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

I think that if method tableNeedsPriority() returns false for this table, that we should not execute the code below that calculates entry priorities. Instead, we should issue a warning or error if the source code contains explicit priority values for any entry.

If the P4 developer tries to specify priority values for such a table, I think they have a fundamental misunderstanding, and should get an error that says something like "This table cannot support entry priorities. For example, tables with only exact and lpm match kinds cannot support entry priorities".

TODO Andy: Create a test program to exercise this case, and expect an error message.

Copy link
Contributor

Choose a reason for hiding this comment

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

Inside the zip file I have attached to this comment: #3748 (comment) the test program init-entries-error1-bmv2.p4 contains 3 different but similar table definitions that I believe should all give an error message at compile time for the reason mentioned in my comment above.

@jafingerhut
Copy link
Contributor

I have attached a zip file to this comment containing 4 new test programs for this issue. Each has one or more table definitions in it, with comments explaining what warnings or errors I would expect the compiler to issue for it. The ones in p4_16_errors currently cause no errors to be issued with the changes in this PR as of commit 4.

p4c-pull-3748-test-progs.zip

@mihaibudiu
Copy link
Contributor Author

Another thing that would be good to have: in the code that determines the entry priorities, save the results of the determined priority values in such a way that the control plane API generation code can read and output those priority values.

This is what we are doing: after this code every entry in a non-const entries table will have a priority.

@fruffy
Copy link
Collaborator

fruffy commented May 26, 2023 via email

@@ -0,0 +1,290 @@
# XFAILS: tests that currently fail. Most of these are temporary.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think something went wrong with the file here.

@jafingerhut
Copy link
Contributor

Is it clear to anyone what might be causing the macOS test failures?

@fruffy
Copy link
Collaborator

fruffy commented Jun 1, 2023

2023-05-26T18:21:40.7270690Z /Users/runner/work/p4c/p4c/frontends/p4/entryPriorities.cpp:77:33: error: call to constructor of 'IR::Constant' is ambiguous
2023-05-26T18:21:40.7276490Z             auto priority = new IR::Constant(currentPriority);

@mihaibudiu
Copy link
Contributor Author

I introduced this bug, but the "pedantic" flag for MacOS produces such huge logs that I could never find it.

@fruffy
Copy link
Collaborator

fruffy commented Jun 1, 2023

Also recommend adding this:
https://github.com/p4lang/p4c/pull/3970/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR241
to get rid of the excessive warnings, it should help.

@fruffy
Copy link
Collaborator

fruffy commented Jun 7, 2023

@mihaibudiu I merged a PR that cleans up the MacOS error message. I believe there is still an error of the same kind left.

Mihai Budiu and others added 12 commits June 7, 2023 11:21
Signed-off-by: Mihai Budiu <mbudiu@vmware.com>
Signed-off-by: Mihai Budiu <mbudiu@vmware.com>
Signed-off-by: Mihai Budiu <mbudiu@vmware.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
Signed-off-by: Mihai Budiu <mbudiu@gmail.com>
@jafingerhut
Copy link
Contributor

Yay! All tests passing, 2 positive reviews. Time to merge? I am happy to do it.

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.

5 participants