feature: p4: initializing tables from p4 program

[jrfastab]

I think this came up previously but would like to revisit.

In some architectures there are tables that can not be written to at run-time but can be programmed via firmware/ucode/etc at init time. Expressing this in P4 is not possible at the moment because the language expects all tables to be programmable at runtime.

To resolve this I have added an extension to an internal prototype compiler that accepts an initialization sequence similar to C style code. For example the following,

table fixed_map() {
key = {packet.parser_output : exact; }
actions = {
act0;
}
default_action = act1(0xdeadbeef);
size = 1024;
} = { 1 : act0(1), 2 : act0(2), 3 : act0(3), 4 : act(4)};

Where the initialization is after the '='. Any thoughts/opinions about adding this to the language proper? The change had fairly minimal impact to both p4 programs and prototype compiler code.

Some example use cases for these fixed tables is to load balance across multiple packet pipelines in a device, provide a way for specified packets to skip certain pipeline components (encryption, etc). In many cases it is fairly difficult (impossible?) for the compiler to infer the fixed table contents from the p4 program itself.

Thanks.

[mihaibudiu]

There is an issue open for this in the P4-16 spec.
The problem is that there are many kinds of tables, and the way you write initializers for them may depend on the kind of table. E.g., LPM, ternary, exact, etc. If the table is read-only we can probably work out a syntax, but if you expect the table to be mutated by the control plane things get more complicated. For example, many ternary tables have also a "priority" field to go with each key. How would you specify that?

[jrfastab]

FWIW an alternative solution is to model the object as an action in front the table in the control flow and this avoids any extensions which might be a better a solution.

[jrfastab]

For my example everything is read-only which is why a static action may be a reasonably good compromise. With regards to priority we've made the assumption that the initialization is done in priority order which seems to be fairly natural for folks familiar with ternary tables but I agree it starts to push lots of assumptions into the language which might be best to avoid.

[mihaibudiu]

The problem is that you may also want specific values for the priorities, not just consecutive values.
We had a proposal where the table contents is specified in a way similar to select statements:

table t() {
    key = { ... }
    actions = { a; b; c; }
    const value = { 
        (0x0F &&& 0x0F) : a(2);
        0xE : b(3);
     }
}

We have postponed a design for the initializer language until the spec about the control plane-data plane API is written. That API will have to specify how tables are initialized, and we'd like to have a similar capabilities (and maybe a similar syntax) in P4 if possible. That spec does not exist yet.

[chkim4142]

Hi John and Mihai,

Can you please have this conversation through the following issue thread
associated with p4-spec?

p4lang/p4-spec#15

I'm not sure if the issue thread associated with p4c is what all p4-design
members are following. Also, it'd be good all the language-design
discussions there and keep p4c only for implementation-related issues.

-- Chang

On Fri, Oct 14, 2016 at 8:46 AM, mbudiu-vmw notifications@github.com
wrote:

The problem is that you may also want specific values for the priorities,
not just consecutive values.
We had a proposal where the table contents is specified in a way similar
to select statements:

table t() {
key = { ... }
actions = { a; b; c; }
const value = {
(0x0F &&& 0x0F) : a(2);
0xE : b(3);
}
}

We have postponed a design for the initializer language until the spec
about the control plane-data plane API is written. That API will have to
specify how tables are initialized, and we'd like to have a similar
capabilities (and maybe a similar syntax) in P4 if possible. That spec does
not exist yet.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#102 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AG-rfNEYWXUapyAkEkOulpwXlImDJNjJks5qz6PqgaJpZM4KWczR
.

[mihaibudiu]

This has been solved by PR #397