-
Notifications
You must be signed in to change notification settings - Fork 449
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
Conversation
This implementation does not have the code to generate the priorities yet, but validates the grammar |
there are a bunch of failures due to the inability to install the software in CI.
I haven't touched this file. |
@smolkaj any clues why bazel is unhappy? |
This is the error message:
Did you make any changes to |
I didn't that's why I find this puzzling. |
@smolkaj Some people say it's a caching bug: https://stackoverflow.com/questions/53527134/bazel-missing-dependency-declarations-for-stddef-h-and-others-ubuntu-18-04 |
You could try clearing the cache here? https://github.com/p4lang/p4c/actions/caches?query=key%3ALinux-build+ EDIT: source: https://stackoverflow.com/questions/63521430/clear-cache-in-github-actions |
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...:
EDIT: An easy workaround that will clear the cache: in
with something like
|
I cleared the cache. Looks like it is fixed. |
} | ||
|
||
control c(in Headers h) { | ||
action a() { |
There was a problem hiding this comment.
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.
@jafingerhut can you please review this? |
@jafingerhut this now uses the syntax with mandatory 'priority' and a colon after the priority |
If we settle on this syntax I will implement the additional features in the spec PR, e.g., priority assignment. |
@jafingerhut the last commit is meant to implement the spec completely with regards to non-const entries |
@mihaibudiu Thanks! I will try to review at least the test cases, and perhaps parts of the implementation regarding generation of warnings, soon-ish. |
I have tested the warning generation too, but was too lazy to add the tests. |
@mihaibudiu Fortunately adding test cases and checking their outputs is my p4c specialty! :-) |
Human p4testgen ;-)
…On Fri, May 19, 2023 at 4:47 PM Andy Fingerhut ***@***.***> wrote:
@mihaibudiu <https://github.com/mihaibudiu> Fortunately adding test cases
and checking their outputs is my p4c specialty! :-)
—
Reply to this email directly, view it on GitHub
<#3748 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOCFUS4TAESGXSFZYBP2PTXG7L65ANCNFSM6AAAAAASRC44VA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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. 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. |
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 |
frontends/p4/entryPriorities.cpp
Outdated
CHECK_NULL(table); | ||
auto ep = table->properties->getProperty(IR::TableProperties::entriesPropertyName); | ||
CHECK_NULL(ep); | ||
if (ep->isConstant) return entries; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
This is what we are doing: after this code every entry in a non-const entries table will have a priority. |
I would just add
p4tools_add_xfail_reason(
"testgen-p4c-bmv2-ptf"
"Error when adding match entry to target"
init-entries-bmv2.p4
)
to the BMV2PTFXfail.cmake file.
|
@@ -0,0 +1,290 @@ | |||
# XFAILS: tests that currently fail. Most of these are temporary. |
There was a problem hiding this comment.
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.
Is it clear to anyone what might be causing the macOS test failures? |
|
I introduced this bug, but the "pedantic" flag for MacOS produces such huge logs that I could never find it. |
Also recommend adding this: |
@mihaibudiu I merged a PR that cleans up the MacOS error message. I believe there is still an error of the same kind left. |
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>
Yay! All tests passing, 2 positive reviews. Time to merge? I am happy to do it. |
Signed-off-by: Mihai Budiu mbudiu@vmware.com
This validates the design in p4lang/p4-spec#1180