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

Opt-out table return value #2

Open
2 tasks
QinshiWang opened this issue Feb 5, 2023 · 0 comments
Open
2 tasks

Opt-out table return value #2

QinshiWang opened this issue Feb 5, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@QinshiWang
Copy link
Collaborator

In P4, tables are often considered free of return value, e.g.

tbl.apply();

But the P4 spec and our semantics describes a return value that is sometimes useful in a if/swtich statement, e.g.

if (ipv4_match.apply().hit) {
    // there was a hit
} else {
    // there was a miss
}
switch (dmac.apply().action_run) {
    Drop_action: { return; }
}

So even in the common case where the return value is ignored, the program logic requires the user to write down the return value. The return value itself is verbose, and I found a slightly better approach using existential quantifier.

Definition tbl_spec : func_spec :=
  WITH (* p *),
    PATH p
    MOD (Some []) []
    WITH,
      PRE
        (ARG []
        (MEM []
        (EXT [])))
      POST
        (EX retv,
        (ARG_RET [] retv
        (MEM []
        (EXT []))))%arg_ret_assr.

But this still requires the user to understand that there is a return value and remember to write it. The user also needs to handle the existential quantifier explicitly when calling this table.

step_call tbl_body.
{ entailer. }
Intros _.

Also, for a table with only one action, e.g.

action act_foo() {
}

table tbl_foo() {
  actions = {
      act_foo();
  }
  default_action = act_foo();
  size = 1;
}

applying the table is just the same as applying the action, so we expect them to have the same func spec. But the difference comes at the return value.

So there are two things we want to have

  • a method to ignore tables' return values in func specs and call sites;
  • the same func spec for an action and its single-action table.

I think the implementation can be making the meaning of ValBaseNull in return values as "any". This will directly solve the two bullet points. It does not break anything else, because ValBaseNull is now used for void functions, whose return values must be ignored.

@QinshiWang QinshiWang added the enhancement New feature or request label Feb 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant