Support dynamic configuration for P4Runtime implementation
The server now exposes a new gRPC service that allows changing some
configuration parameters of the P4Runtime implementation. At the moment
we only support enabling / disabling stream error-reporting (recently
added to the P4Runtime specification).
For software that consumes DeviceMgr directly and does not use the
server code included in this project, we have added a new method to the
DeviceMgr PIMPL which enables updating the configuration.
This change also implements support for stream error-reporting (when
enabled through the configuration mechanism described above). At the
moment we only report errors for invalid PacketOut messages. StreamError
messages could have been "injected in the stream" in 3 different places:
(1) in the PacketIOMgr, (2) in the DeviceMgr, or (3) in the DeviceMgr
client. In this patch we went with (2) to avoid changing the DeviceMgr
interface (3) and to avoid making the assumption that components which
handle PacketOut messages must also have the ability to send PacketIn
messages (1), even though this is currently the case for all the
components we have.
The P4Runtime spec states that StreamError messages may be dropped if
the StreamChannel is too busy. We consider that this is not the
responsibility of DeviceMgr, but of the DeviceMgr client (e.g. P4Runtime
service implementation). This is probably a good idea for the client to
implement such a mechanism. Our current P4Runtime service implementation
does not, and if a StreamError message needs to be sent to the P4Runtime
client, we will not accept a new StreamMessageRequest until the
StreamError message is sent. This could impact PacketOut performance,
but then again stream error-reporting is only meant to be enabled for
debugging purposes.
This ensures that the core PI library and the target-specific PI
implementation are "ABI-compatible". Or in other words it ensures that
the PI library which was used to build the target-specific PI
implementation is the "same" as the PI library which ultimately is
linked with the target-specific PI implementation. The purpose of this
is to avoid some runtime issues / crashes which can be hard to debug.
This is a poor man workaround. Ideally we could try to rely on something
like library SONAME, but at the moment targets are free to provide their
PI implementation in any form they want, including as part of a larger
SDK library.
Better cleanup in DeviceMgr when pi_mc_* calls fail
* in case of a target failure during group creation, we cleanup all
created nodes and the group itself
* in case of a target failure when creating & adding new nodes to an
existing group, we cleanup the newly created nodes (and keep the
existing ones)
We currently assume that only the following operations will fail: group
create, node create, node attach. We don't have any specific cleanup
logic for other possible failures.
The oneshot implementation and "manual" implementation (manual group &
member management) are now split into 2 different classes.
I haven't found a nice way to cleanup the code that is dependent on the
PI API being used by the ActionProfMgr
(PI_ACT_PROF_API_SUPPORT_GRP_SET_MBRS or
PI_ACT_PROF_API_SUPPORT_GRP_ADD_AND_REMOVE_MBR).
