You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ask because I tried a test using a P4Runtime API client connecting to infrap4d over a P4Runtime connection, and attempted to add an entry to a table with an action that had one or more parameters that were 128 bits in size, but they failed. When I changed those parameters to 64 bits wide instead, they seemed to succeed in being added, or at least did not get the same error return status back as when I tried it with 128-bit wide action parameters.
The text was updated successfully, but these errors were encountered:
Note: I was testing with infrap4d built as part of the IPDK network container, built according to the published instructions. As of 2024-Feb-20, those instructions seem to build the 23.07 version, not the 24.01 version.
This test P4 program should be just about the smallest difference between two simple P4 programs that demonstrates that with IPDK networking container v23.07, if you attempt to add an entry to a table with an action that has a parameter with type bit<128> via the P4Runtime API, it causes the infrap4d process to crash. Without that action parameter, everything appears to be working correctly: https://github.com/jafingerhut/p4-guide/tree/master/ipdk/testprog3
I have not checked this, but it is possible that this issue is only with the P4Runtime API implementation layered on top of P4-DPDK's "native" table modification operations. If the "native" table modification operations support this today, it would be nice to have a link to any documentation what those native APIs are.
I ask because I tried a test using a P4Runtime API client connecting to infrap4d over a P4Runtime connection, and attempted to add an entry to a table with an action that had one or more parameters that were 128 bits in size, but they failed. When I changed those parameters to 64 bits wide instead, they seemed to succeed in being added, or at least did not get the same error return status back as when I tried it with 128-bit wide action parameters.
The text was updated successfully, but these errors were encountered: