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
And record the result in some table summarizing tested-working features of BMv2 and P4-DPDK. Report the results back to the DASH behavioral model work group. Consider expanding the table to include other open source P4 implementations like P4TC, P4-EBPF, etc., with the help of implementers of those targets.
cloning a packet
and modifying the clone after it has been created, so it is different than the original packet, including truncation
sending packets to a CPU port that causes them to become P4Runtime controller PacketIn messages
in particular, can cloned packets be sent to the control plane in this way?
injecting packet into P4 data plane via P4Runtime controller sending a PacketOut message
and are such packets easily separable from packets received on "normal ports" in the P4 program, e.g. because their input port is equal to one of a small set of specially designated CPU ports (perhaps with a set size of 1)?
digest message extern, including that digest messages become asynchronous messages over a P4Runtime API gRPC connection to the P4Runtime controller?
does the implementation support batching of multiple such digest messages into one controller message?
how many different Digest externs are supported for a single P4 program?
The text was updated successfully, but these errors were encountered:
I have learned that it is definitely supported to send packets from P4 DPDK to control plane code, and in the opposite direction, via a normal TAP interface, as long as the control plane software listens for packets received on that TAP interface, and/or sends packets to it. This is just a plain old normal TAP interface as far as P4 DPDK is concerned. The packets sent from the P4 DPDK software switch on such a normal TAP interface do not become PacketIn messages to the infrap4d P4Runtime API clients, and PacketOut messages from a P4Runtime API client do not become packets sent on such a TAP interface.
There might be a supported way for P4Runtime API clients of infrap4d to use PacketIn and PacketOut messages, but if so, I have not learned how to do so as of 2024-Mar-02.
If packet mirroring works in P4 DPDK, I do not know how to configure those mirror sessions from a P4Runtime API client yet. P4 programs that use the PNA mirror_packet extern function compile, and become unique kinds of actions in the .spec files output by p4c-dpdk, but I do not know how to make that mirroring actually happen. Perhaps it is possible if you use Python TDI calls from the CLI with the bf_switchd process, but I have not verified that myself.
And record the result in some table summarizing tested-working features of BMv2 and P4-DPDK. Report the results back to the DASH behavioral model work group. Consider expanding the table to include other open source P4 implementations like P4TC, P4-EBPF, etc., with the help of implementers of those targets.
cloning a packet
sending packets to a CPU port that causes them to become P4Runtime controller PacketIn messages
injecting packet into P4 data plane via P4Runtime controller sending a PacketOut message
digest message extern, including that digest messages become asynchronous messages over a P4Runtime API gRPC connection to the P4Runtime controller?
The text was updated successfully, but these errors were encountered: