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

API for KV-tables #2739

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

API for KV-tables #2739

wants to merge 1 commit into from

Conversation

mihaibudiu
Copy link
Contributor

Marking as draft PR, since this needs support for unions.
To be accompanied by support in the compiler for some back-ends and test cases.

@jfingerh
Copy link

@mbudiu-vmw I was reminded of this PR in an Intel-internal discussion, and we may want to use a variant of one of these extern objects you propose, one that does not need the union keyword.

One variant of this could be restricted to only have exact match key fields, but in looking at your proposed extern object definition that takes a list of match_kind values, do you have an example instantiation of such an extern object that would use match_kind values other than exact that gives no errors with the latest p4test command? I tried briefly to find one, but kept getting syntax error messages that appeared to come from the parser.

@mihaibudiu
Copy link
Contributor Author

We should write some tests. Your question is really independent on the patch, it would even apply to cases like:

extern void f<T>(in T data);
... 
f(ternary);
f(match_kind.ternary);

This should in principle work, but if it doesn't we may need to tweak the grammar.

@jfingerh
Copy link

jfingerh commented Feb 22, 2022

The program named v1model_valuelut_matchkinds2.p4 in the attached ZIP file fails to compile with the latest p4test, and contains several commented-out lines that also fail to compile. There might be some variation I have not tried that works, but if so, I am not sure what it would be.

The attached code includes a slightly different definition of a ValueExactLookupTable that avoids the issue, but is intended to be restricted to all exact match_kind values for all key fields.
lookup-table-externs.zip

@mihaibudiu
Copy link
Contributor Author

perhaps you should file that as a new issue... It will get lost here. At least if we expect the program to compile.
Do we need to discuss this in the LDWG?

@jfingerh
Copy link

Created this issue: #3091

@mbudiu-vmw It would be wonderful if you could take a look at the example program and compile-time error messages attached to that issue, and see whether you think these look like they raise questions for the LDWG, or if they are perhaps easily-enhanced things in the existing compiler implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p4-spec Topics related to the P4 specification (https://github.com/p4lang/p4-spec/).
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants