How to implement idle timeout for table entries?

1

Hi,

I read in the P4Runtime specification that it supports idle timeout for table entries. But I am not able to find anything that will help me implement IdleTimeoutNotification in the helper files provided in the p4 tutorials. Any insight regarding this will be highly helpful.

Cheers!

2

I created a simple P4_16+v1model architecture program that can run on bmv2, and an automated PTF test that uses the P4Runtime API to communicate between the controller and switch, and shows the contents of all idle timeout notification messages sent from the bmv2 switch to the controller. You can find instructions for running it here: p4-guide/ptf-tests/idletimeout at master · jafingerhut/p4-guide · GitHub

3

Hi @andyfingerhut ,
I encounter a problem with idle_timeout and would like to ask for your advice. I do the test by using p4runtime-shell to add rules with idle_timeout in a bmv2 switch. While all other parts of the rules (e.g., match, action, priority (if relevant)) can be added in the switch successfully, the idle_timeout seems to be never active in the switch. I have checked that in the switch with simple_switch_CLI, and also tried to catch idle_timeout_notification but could not see any. I add some details below to be more clear.

Part of the test_idletimeout.p4 file:

table dmac {
        key = {
            hdr.ethernet.dstAddr: exact;
        }
        actions = {
            forward;
            send_to_cpu;
            NoAction;
        }
        support_timeout = true;
        default_action = send_to_cpu;
    }

I can compile the above p4 file successfully with the command:

p4c-bm2-ss --p4v 16 --p4runtime-files test_idletimeout.p4info.txt -o test_idletimeout.json test_idletimeout.p4

and run the bmv2 switch with:

sudo simple_switch_grpc -i 1@eth1 -i 2@eth2 -i 3@eth3 -i 4@eth4 -i 5@eth5 --pcap pcaps --nanolog ipc:///tmp/s1-log.ipc --device-id 1 test_idletimeout.json --log-console --thrift-port 9090 -- --grpc-server-addr 172.16.0.51:50051 --cpu-port 255

Then, p4runtime-shell as the controller:

python3 -m p4runtime_sh --grpc-addr 172.16.0.51:50051 --device-id 1 --election-id 0,1 --config test_idletimeout.p4info.txt,test_idletimeout.json
te = TableEntry('dmac')(action='forward')
te.match['dstAddr'] = '00:00:01:01:ff:ff'
te.action['egress_port'] = '3'
te.idle_timeout_ns = 12345
te.insert()

Using simple_switch_CLI, I can see the rule in the switch as follow:

TABLE ENTRIES
**********
Dumping entry 0x0
Match key:
* ethernet.dstAddr    : EXACT     00000101ffff
Action entry: MyIngress.forward - 03
==========
Dumping default entry
Action entry: MyIngress.send_to_cpu -

As said, there is no idle_timeout_notification sent from the switch to the control plane at all, also no hint on idle_timeout in the rule shown via simple_switch_CLI.

However, if I set idle_timeout for that entry by simple_switch_CLI command:

table_set_timeout dmac 0 1000

then I can observe the rule in the switch with idle_timeout being set (also with simple_switch_CLI) as below, and also I can catch some idle_timeout_notification in the control plane:

TABLE ENTRIES
**********
Dumping entry 0x0
Match key:
* ethernet.dstAddr    : EXACT     00000101ffff
Action entry: MyIngress.forward - 03
Life: 17495ms since hit, timeout is 1000ms
==========
Dumping default entry
Action entry: MyIngress.send_to_cpu -

Therefore, I believe p4runtime-shell has not set idle_timeout successfully in the switch.
Could you please give me some advice on this problem? Have I missed something while using p4runtime-shell to set idle_timeout?
Many thanks.
Cheers!
Cuong

4

Have you tried running the PTF test that I link in my earlier message above? Because it does not use the simple_switch_CLI to configure anything, and it does cause idle timeout notifications to be generated from the switch to the P4Runtime client.

I have not checked yet whether you might be doing something different than I am using in my PTF test example, but perhaps you can try it out to see if that PTF test also passes for you, and see if there is anything different about your example and mine.

5

I have tried the PTF test for idle_timeout, that worked well (for other audiences: it is important to run the script https://github.com/p4lang/p4factory/blob/master/tools/veth_setup.sh to set up the infrastructure beforehand, so that the PTF test can be successful).
I tried again with my own setup, generated real traffic in the data plane (with ping command) and let the controller install rules with idle_timeout in reaction to packet-in events, then I can see timeout of rules in the switch (using simple_switch_CLI) and also catch the idle_timeout_notification for these rules.
For those rules that I installed manually and independently from the traffic, there was no timeout and notification, though I set idle_timeout for them explicitly.
I am not sure about the above behaviour of P4 switch (and possibly P4Runtime is also involved). In OpenFlow, I can always set hard_timeout and idle_timeout, no matter how I install the rule (independently from traffic or in reaction to incoming traffic).
Anyway, I am able to set idle_timeout for rules and get notifications in some way.
Thanks!

6

I am not certain, but perhaps there is some behavior where the idle timeout notifications are only sent to the same client that installed the table entries? I have not experimented to find out whether that is the case. Note that in the example I linked, there is only ever ONE P4Runtime API client, and it both installs the entries, and receives the later idle timeout notifications for those entries. I have never tried it with multiple P4Runtime API clients.

1 Like