Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
p4tc: add table create, update, delete, get, flush and dump
This commit introduces code to create and maintain P4 tables within a P4
program from user space and the next patch will have the code for
maintaining entries in the table.
As with all other P4TC objects, tables conform to CRUD operations and
it's important to note that write operations, such as create, update and
delete, can only be made if the pipeline is not sealed.
Per the P4 specification, tables prefix their name with the control block
(although this could be overridden by P4 annotations).
As an example, if one were to create a table named table1 in a
pipeline named myprog1, on control block "mycontrol", one would use
the following command:
tc p4template create table/myprog1/mycontrol/table1 tblid 1 \
keysz 32 nummasks 8 tentries 8192
Above says that we are creating a table (table1) attached to pipeline
myprog1 on control block mycontrol which is called table1. Its key size is
32 bits and it can have up to 8 masks and 8192. The table id for table1 is
1. The table id is typically provided by the compiler.
Parameters such as nummasks (number of masks this table may have) and
tentries (maximum number of entries this table may have) may also be
omitted in which case 8 masks and 256 entries will be assumed.
If one were to retrieve the table named table1 (before or after the
pipeline is sealed) one would use the following command:
tc p4template get table/myprog1/mycontrol/table1
If one were to dump all the tables from a pipeline named myprog1, one would
use the following command:
tc p4template get table/myprog1
If one were to update table1 (before the pipeline is sealed) one would use
the following command:
tc p4template update table/myprog1/mycontrol/table1 ....
If one were to delete table1 (before the pipeline is sealed) one would use
the following command:
tc p4template del table/myprog1/mycontrol/table1
If one were to flush all the tables from a pipeline named myprog1, control
block "mycontrol" one would use the following command:
tc p4template del table/myprog1/mycontrol/
___Table Permissions___
Tables can have permissions which apply to all the entries in the specified
table. Permissions are defined for both what the control plane (user space)
is allowed to do as well as datapath.
The permissions field is a 16bit value which will hold CRUDX (create,
read, update, delete and execute) permissions for control and data path.
Bits 9-5 will have the CRUDX values for control and bits 4-0 will have
CRUDX values for data path. By default each table has the following
permissions:
CRUD--R--X
Which means the control plane can perform CRUD operations whereas the data
path can only Read and execute on the entries.
The user can override these permissions when creating the table or when
updating.
For example, the following command will create a table which will not allow
the datapath to create, update or delete entries but give full CRUD
permissions for the control plane.
$TC p4template create table/aP4proggie/cb/tname tblid 1 keysz 64
permissions 0x349 ...
Recall that these permissions come in the form of CRUDXCRUDX, where the
first CRUDX block is for control and the last is for data path.
So 0x349 is equivalent to CR-D--R--X
If we were to do a get with the following command:
$TC p4template get table/aP4proggie/cb/tname
The output would be the following:
pipeline name aP4proggie pipeline id 22
table id 1
table name cb/tname
key_sz 64
max entries 256
masks 8
table entries 0
permissions CR-D--R--X
Note, the permissions concept is more powerful than classical const
definition currently taken by P4 which makes everything in a table
read-only.
___Initial Table Entries___
Templating can create initial table entries. For example:
tc p4template update table/myprog/cb/tname \
entry srcAddr 10.10.10.10/24 dstAddr 1.1.1.0/24 prio 17
In this command we are "updating" table cb/tname with a new entry. This
entry has as its key srcAddr concatenated with dstAddr
(both IPv4 addresses) and prio 17.
If one was to read back the entry by issuing the following command:
tc p4template get myprog/table/cb/tname
They would get:
pipeline id 22
table id 1
table name cb/tname
key_sz 64
max entries 256
masks 8
table entries 1
permissions CRUD--R--X
entry:
table id 1
entry priority 17
key blob 101010a0a0a0a
mask blob ffffff00ffffff
create whodunnit tc
permissions -RUD--R--X
___Table Actions List___
P4 tables allow certain actions but not other to be part of match entry on
a table or as default actions when there is a miss.
We also allow flags for each of the actions in this list that specify if
the action can be added only as a table entry (tableonly), or only as a
default action (defaultonly). If no flags are specified, it is assumed
that the action can be used in both contexts.
In P4TC we extend the concept of default action - which in P4 is mapped to
"a default miss action". Our extension is to add a "hit action" which is
executed every time there is a hit.
The default miss action will be executed whenever a table lookup doesn't
match any of the entries.
Both default hit and default miss are optional.
An example of specifying a default miss action is as follows:
tc p4template update table/myprog/cb/mytable \
default_miss_action permissions 0x109 action drop
The above will drop packets if the entry is not found in mytable.
Note the above makes the default action a const. Meaning the control
plane can neither replace it nor delete it.
tc p4template update table/myprog/mytable \
default_hit_action permissions 0x30F action ok
Whereas the above allows a default hit action to accept the packet.
The permission 0x30F in binary is (1100001111), which means we have only
Create and Read permissions in the control plane and Read, Update, Delete
and eXecute permissions in the data plane. This means, for example, that
now we can only delete the default hit action from the data plane.
__Packet Flow___
As with the pipeline, we also have preactions and postactions for tables
which can be programmed to teach the kernel how to process the packet.
Both are optional.
When a table apply() cmd is invoked on a table:
1) The table preaction if present is invoked
2) A "key action" is invoked to construct the table key
3) A table lookup is done using the key from #2
4a) If there is a hit
- the match entry action will be executed
- if there was a match and the entry has no action and a default hit
action has been specified then the default hit action will be executed.
4b) If there was a miss
- if there was a default miss action it will be executed then
5) if there is table post action then that is invoked next
Example of how one would create a key action for a table:
tc p4template create action/myprog/mytable/tkey \
cmd set key.myprog.cb/mytable \
hdrfield.myprog.parser1.ipv4.dstAddr
and now bind the key action to the table "mytable"
$TC p4template update table/myprog/cb/mytable \
key action myprog/mytable/tkey
Example of how one would create a table post action is:
tc p4template create action/myprog/mytable/T_mytable_POA \
cmd print prefix T_mytable_POA_res results.hit \
cmd print prefix T_mytable_POA hdrfield.myprog.parser1.ipv4.dstAddr
Activate it..
tc p4template update action/myprog/mytable/T_mytable_POA state active
bind it..
$TC p4template update table/myprog/cb/mytable postactions \
action myprog/mytable/T_mytable_POA
Co-developed-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Co-developed-by: Pedro Tammela <pctammela@mojatatu.com>
Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>- Loading branch information
1 parent
dc5e6ef
commit a3f3b24