Question: in-process variant of P4Runtime API?

[jafingerhut]

This is a question right now, not really a feature request.

The P4Runtime API is pretty fundamentally a message-based protocol. Has there been any interest in creating a 'in the same process' C/C++/Java/some-other-language API that is based on the P4Runtime API? I know we can run P4Runtime over gRPC between two processes on the same CPU, of course, but that is not quite the same thing.

[antoninbas]

You can use the P4Runtime Protobuf messages without gRPC as the RPC mechanism. This is what this C++ API does: https://github.com/p4lang/PI/blob/master/proto/frontend/PI/frontends/proto/device_mgr.h. I would consider it "semi-standard" since it uses the standard P4Runtime Protobuf messages but it is not itself produced by the P4 API WG. It is however used by Stratum to interface with bmv2 and the Barefoot Tofino drivers. You will notice that the arbitration messages are not handled by the C++ API. It is assumed that this is handled by an upper layer, like in Stratum. This also makes sense when using this API to write a local controller running in-process.

[stolsma]

@jafingerhut I had this idea popping up in discussions with other people (related to p4 eBPF/OpenvSwitch) about 6 weeks ago but didn't follow up on it. Will check if they are still interested... @antoninbas nice implementation! Will check it out in more detail!

[jfingerh]

Thanks for the info @antoninbas

If I understand correctly, using this API still requires a client to do marshaling of Protobuf messages in memory before calling functions in the API, and unmarshaling/decoding/etc. of Protobuf messages it receives back as return values?

I am guessing the sweet spot would be that every client thread would effectively be one P4Runtime API client?

Would it make any sense for a single client thread to try to behave like more than one P4Runtime API client? The implementation you link to might not even enable that, and I cannot think of a strong reason to want such an arrangement. I am primarily asking to see where the parts of the map are labeled 'here be dragons', versus 'this is well sailed territory'.

[antoninbas]

There is no marshaling / unmarshaling. You create C++ Protobuf objects as inputs and get C++ Protobuf objects as outputs, but these are never serialized as they are never sent on the wire, or written to disk. It's really similar to using C/C++ structs, but we avoid defining new types.

I am not sure I understand the second part of the questions. The C++ API supports multi-threaded access (because it is used to implement the P4Runtime gRPC service, in which different RPCs may be served by different threads), so the entire process and all its threads may be considered one client. You cannot actually choose to have multiple "clients", as the API doesn't handle arbitration, but that wouldn't make sense anyway to have several "clients" in the same process, except for testing maybe.