-
Notifications
You must be signed in to change notification settings - Fork 92
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
Added Structured Annotations #265
Conversation
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.
Could we use a simpler proto representation that makes it clear whether we are dealing with a list or kvpairs (like in the grammar)? Maybe something along the lines of:
message KeyValuePair {
string key = 1;
Expression value = 2;
}
message KeyValuePairList {
repeated KeyValuePair elements = 1;
}
message Expression {
oneof value {
string string_value = 1;
int64 int64_value = 2;
bool bool_value = 3;
List list_value = 4;
}
}
message List {
repeated Expression expressions = 1;
}
message StructuredAnnotation {
string name = 1;
oneof body {
List list;
KeyValuePairList kvpair_list = 2;
}
}
This also means the invariants become much simpler, as there cannot be empty keys.
@stefanheule Thanks for the fast review, that's a nice suggestion. I'm open to anything reasonable. Let's get more feedback, I'm happy to refactor to the best consensus solution. |
Actually, thinking about it, it is not clear to me from the spec if constant list expressions are allowed or not. If they are not, then the protos can be even more simplified. If they can, the spec should probably be updated to say that. Right now it says:
That, to me, says there are no lists? But I'm not sure what the "nested expressions" means. |
@stefanheule "Nested expressions" was meant to include the case where an expression is an {expressionList}, to handle casaes like MyAnno[x=10,y={a,b,c}] - it might be very desirable to have the value of a kv-pair be a list of constant epressions. |
I think that probably needs to be made more precise then. There are a number of nested expressions in P4, and most of them are not allowed (e.g. {kvlist}). |
@stefanheule Good feedback, Could you be so kind as to make that comment in the P4-Spec PR then? I welcome improvements to it. Thanks! |
Done. |
@stefanheule I tried out your proposed revised syntax against the examples I'd provided and indeed it is cleaner and more concise. Here is the a slightly-revised version of it, followed by the original example P4info and the revised P4info using the new syntax. For just these 4 simple examples, the revised P4info is 25 lines shorter (around 25% reduction). I'm in favor of changing to it, thanks for the suggestion. I'll wait a bit for more feedback, then proceed to update the PR accordingly. Revised
Old P4Info for the examples:
Revised P4Info:
|
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 started reviewing this and then realized you had not updated the code with your latest changes yet.
So regarding the latest proposal in #265 (comment): it looks good to me. I see that for the sake of unifying the expression-list case and the KV case, we now allow nested expression lists in P4Info - which wasn't the case in your original proposal. Is the following also valid in P4?
@NestedExprLists[1,TEXT_CONST,true,1==2,{1, 2, {5, 6}}]
Based on p4lang/p4-spec#796 it looks like it is indeed legal, in which case it makes sense to support in P4Info. You may consider also including this example (or one like it) in the spec.
I didn't review the rest of the diff in details (I will after you update the code), but do you think it would be possible to add a note about integer expressions which cannot be represented with an int64
? IIRC this is something we discussed at a WG meeting and the decision was that we would not support this in P4Info (and that the compiler would print an error suggesting the user to switch to a string instead).
…ons example and made additional clarifications.
…runtime into chris/structured-annos
@stefanheule @antoninbas (and anyone else) please review simplified |
Co-Authored-By: Antonin Bas <[email protected]>
Co-Authored-By: Antonin Bas <[email protected]>
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.
LGTM
If you can indulge me for one more thing, could you use P4Info
instead of `P4Info`
and p4info
, in order to be consistent with the rest of the spec.
I believe all issues discussed have been resolved in this PR and it is ready for merge. |
… to agree with latest P4-16 spec in progress.
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.
LGTM
Alright, I think this PR has been open for long enough. Merging it now and we can make adjustments later if needed. |
@antoninbas Thanks, I was about to throw it a birthday party! :) |
BTW, the issues in p4-spec are settling down, I've clarified a number of things. There will need to be some minor changes in handling duplicate annotations. |
This PR updates p4info.proto and p4types.proto as well as the P4Runtime specification to add structured annotations as described in #264 and p4lang/p4-spec#796. The P4_16 lang spec PR is not yet ratified, it is awaiting a practical implementation in
p4c
so one goal of this PR is to inform an implementation. Step one is to parse the syntax, step two is to generate the newP4info
.