p4runtime probe reachability is based on GetPipelineConfig gRPC that
can timeout if we are setting in parallel the pipeline: the two requests
concur for the same lock. For our purposes it is enough to check if the
device is still there; for this reason stratum handshaker now relies
on gNOI reachability which is based on getTime RPC.
Additionally increase short timeouts: we have consistenly measured a
time of 14s to push the pipeline on the new QS devices.
Change-Id: I8837540241d8a68f648e47ae165ea53a2d0a865c
When using logical port for replica such as SDN CPU port (0xfffffffd), the
PreReplicaCodec will throw an ArithmeticException since this value is too
big for an signed 32-bit integer.
In that example, we need to convert the value to -3
According to the protobuf document[1]:
"In Java, unsigned 32-bit and 64-bit integers are represented using their
signed counterparts, with the top bit simply being stored in the sign bit."
[1]: https://developers.google.com/protocol-buffers/docs/proto#scalar
Change-Id: Ie3bda828d499b7d26d7b790f9ed76bb687243e57
The field `pkg_info:arch` is now parsed, when parsing a P4Info file.
Change-Id: Ia1b24b929fe4ed8ac2a2becfa0ce7678642e9037
(cherry picked from commit ce9942049825c51c0a0818ad4b89395321aa82b3)
The submit() method of p4 WriteRequestImpl is returning an empty
response if there are no update messages. However, one of the reasons
for updates to be empty is the fact the catch block in
appendToRequestMsg is reached due to some invalid usage of the p4runtime
contract. In such situations, not only the user doesn't know why the
request is failing (absence of logging in ONOS) but the responseBuilder
which contains the failure is also not propagated. As a result, a future
call to P4RuntimeWriteClient.WriteResponse.isSuccess() will return
true (as if the request actually succeeded) and .all() will also not
contain the failedResponse appended during the CodecException. Added a
test to illustrate the issue.
Change-Id: I0acfd3b34b3ed1db2d91f91fed08f9d00800dda4
- Improve ONOS cli enabling CRUD of p4rt trtcm
- Improve ONOS rest enabling CRUD of p4rt trtcm
- Improve MeterService with scope defined reads and integrate in cli/rest
- Add support along the stack for BYTE_PER_SEC unit
- Add support along the stack for COMMITTED and PEAK bands
- Fix several bugs in ONOS cli/rest interfaces
- Improve REST codecs
- Fix NPE in MeterDriverProvider
- Improve PiMeterTransalation by enforcing trtcm config
- Implement explicit translation of the bands
- Fix ONOS reconciliation by removing from the mirror the wrong configs
- Remove unnecessary checks in MeterEntryCodec
- Update unit tests
It will follow a 2nd patch to complete SDFAB-527
Change-Id: I855235b17f60cb1d39f5b9a042c1015105a8a269
A P4 table annotated with @oneshot annotation can be programmed
only with the action profile action set. For these kind of tables
we don't issue read request for action profile groups and members.
Change-Id: I7b6a743f4f4df4190f17d958ebb4807aca5feda5
The P4Runtime server may send canonical byte strings (i.e.,
non-padded byte strings).
In ONOS we ensure, in the codecs, that all byte strings are
padded to match the model (P4Info) bit width. In this way,
we provide read-write symmetry inside ONOS.
ONOS always pads byte strings when sending messages to the
P4Runtime server.
This patch doesn't enforce read-write symmetry between
P4Runtime client and server on the wire.
N.B.: the current padding implementation works ONLY when
using non-negative integer.
Change-Id: I9f8e43de015bd0929dd543d7688c8e71bf5fe98d
Some PI elements can encode in their value a string (e.g., when
a P4Runtime translation is used), for this reason we allow users
to specify matches and action parameters as strings.
From southbound, during decode, we interpret the elements as
string if the P4 model suggests that.
Change-Id: I5884de1500437ab647abc200d65de442e23bd1a8
log:set TRACE org.onosproject.p4runtime.ctl.client.WriteRequestImpl
to have all the prints we need
Change-Id: Ie46e36145769ffc7a91485ee3f3791a94cf8b8a9
This is required for targets that are not P4RT-compliant
and do not support table-specific wildcard reads.
The all tables wildcard read are activated via
tableWildcardReads driver property.
Change-Id: I675e6f876648ad7634ea0a13ecf44aa366739d3f
New master after taking over a switch was pushing again the pipeline
and all the flows and groups. This was happening because DefaultPiPipeconf
fingerprint was not calculated in a deterministic way across the cluster.
This patch introduces the following changes:
- Implements toString method in each abstraction representing a pipeline
- Hashes the p4Info file to generate a consistent hash of the pipeline model
- Uses a sorted collection to generate a consistent hash of the extensions
Change-Id: I792283b0a9b821284add36b3aba52843f33527c3
This commit goes into the direction of supporting user-defined types in P4Runtime.
The modification is focusing on supporting fields and params with arbitrary bit width, that is the
case of using a String with the p4runtime_translation annotation on the user-defined type.
Change-Id: I7db7a6d97211378ff78ab4f1b3734a0bec4558e6
Before, we were reading counters from all tables, even from those that
didn't have any. That was causing certain P4RT implementations to
return error.
Change-Id: I028ecaca46ddc0c9afc16b78ba7754f943a2717b
(cherry picked from commit d172435433e19b10eb6b320823428e67f6205e8a)
This change make it possible to build ONOS in a host system without JDK
installed, or ignoring the one installed, instead relying exclusively on
the "remote" JDK provided by Bazel. The JDK version, along with the
toolchain configuration (language source and target values), are checked
in as part of the build files (tools/build/bazel/BUILD), thus enabling
deterministic builds that are less dependent of the host environment.
To allow this, this change replaces all references to JDK-related tools
expected to be on the host PATH, such as the jar command, with their
counterpart from the remote JDK (now a sandboxed relative path). This is
achieved by:
* Creating a new "jdk_genrule" macro that exposes the remote JDK bin
directory to the PATH visible by the genrule command. This is used
for all genrule targets invoking for example `jar`;
* Modifying custom Starlak rule implementations by replacing
invocation to JDK tools with a path from the remote one.
* Renaming the onos/lib directory to onos/deps as it clashes with
the Bazel-provided JDK's lib directory (that for some strange reason
is resolved on the ONOS workspace)
Finally, this change is reflected on the Dockerfile which now builds
ONOS from an Ubuntu image with no JDK installed.
Change-Id: Ie7d990cfce6fef00ddb4ffffe4c6205b8530fb47
Includes:
- Bump protobuf to 3.8.0 and grpc-java to 1.21.0 (along with transitive
dependencies such as Netty)
- Add jaxb_api at compile time when needed (removed in JDK 11)
- Bump Bnd to 4.1 (adds support for Java 11)
To build with JDK 11, uncomment lines in .bazelrc.
Tested with Bazel 0.26.0.
Change-Id: Ib8e0c7310eacf97328762606e57c01e4834e5565
Without waiting for the next pipeconf watchdog periodic probe.
To support this, this patch extends the PiPipeconfService to advertise
pipeconf registration events.
Change-Id: Ib44f1813bd37083c666a5e7980de320ce469c2d2
This prevents loading potentially large amount of data in memory when
doing pipeconf reconciliation, as well as unregistering a pipeconf while
devices are using it (since we no longer need to access the
target-specific extensions to generate the device data blob)
Change-Id: Ib54123ce49a931ff88d93c991244d4086e5d7de0
Clone sessions can now be created by defining groups with new type CLONE
The PI framework has been refactored to abstract commonality between
multicast groups and clone sessions as both are managed as part of the
P4Runtime packet replication engine (PRE).
Change-Id: I2f23c629b7de1931d5cab96ec76aef26130ce418
Force reset of gRPC connection backoff when probing for reachability.
This allows provider to attempt reconnection when needed, instead of
depending on the channel backoff timer.
Improved checkup task in GDP to better handle mastership
flapping observed when reconnecting devices.
Change-Id: I473fb14160b2eb744a483de431b91f9f6bcdab95
- Push ports before device is marked online
- Do not notify role NONE on device disconnection (otherwise the
DeviceManager won't mark the device as offline if there's not a master)
- Detect changes in the pipeconf extensions when reloading a pipeconf
Change-Id: I1779987da1269ec98c71b2ccda7bb579be5bf3f0
This change introduces a refactoring of the gRPC protocol subsystem that
allows the creation of a gRPC chanel independently of the client, while
allowing multiple clients to share the same channel (e.g. as in Stratum
where we use 3 clients).
Moreover, we refactor the P4RuntimeClient API to support multiple
P4Runtime-internal device ID using the same client. While before the
client was associated to one of such ID.
Finally, we provide an abstract implementation for gRPC-based driver
behaviors, reducing code duplication in P4Runtime, gNMI and gNOI drivers.
Change-Id: I1a46352bbbef1e0d24042f169ae8ba580202944f
The P4RuntimeClient implements a deferring mechanism to avoid becoming
master when it shouldn't, i.e. when the requested election ID is bigger
than the master one on the device, but it was not asked to be master.
We rely on a distributed primitive to make sure all nodes are aware of
the latest master election ID on the device. In case we lose primitive
update events, this patch adds a maximum timeout after which the
MasterArbitrationUpdate message is always sent.
Change-Id: I98669dac3fc79173b9e98f41e11a4d08901c6cb1
- Do not read counters with table entries for Barefoot drivers
- If driver behavior setup fails, log which operation we are aborting
- Remove unnecessary setup steps in Stratum-related drivers
- Always get clients by their key in gRPC-based drivers
- Log when P4Runtime group operation fails because of missing group in
store
- Fix polling of table entry counters for P4Runtime driver
Change-Id: Ic9bf19b76d8cb5a191aec24852af4410fea8b998
This is a temporary workaround to the inability of p4c to
correctly interpret P4Runtime-defined @max_group_size annotations.
Change-Id: If2799786c135b2eb5b6a3b4c6d6022350d37237e
This change also includes:
- Refactoring of gNMI protocol+driver to take advantage of the recent
changes to the gRPC protocol subsystem (e.g. no more locking, start RPC
with timeouts, etc.).
- Fixed Stratum driver to work after GeneralDeviceProvider refactoring
- Updated bmv2.py to generate ChassisConfig for stratum_bmv2
- Fixed portstate command to use the same port name as in the store
Change-Id: I0dad3bc73e4b6d907b5cf6b7b9a2852943226be7
This is achieved by optimistically updating the P4Runtime mirror using
the write request (instead of waiting for a response) and by serializing
building write requests for the same device.
This change requires updating the P4Runtime protocol classes to expose
the content of the write request.
It also includes:
- force member weight to 1 when reading groups (some server
implementation still fails to be compliant to the spec)
- remove unused operation timeout handling in GDP (now all RPCz have a
timeout)
Change-Id: Ib4f99a6085c1283f46a2797e0c883d96954e02e9
This (big) change aims at solving the issue observed with mastership flapping
and device connection/disconnection with P4Runtime.
Channel handling is now based on the underlying gRPC channel state. Before,
channel events (open/close/error) were generated as a consequence of P4Runtime
StreamChannel events, making device availability dependent on mastership. Now
Stream Channel events only affect mastership (MASTER/STANDBY or NONE when the
SteamChannel RPC is not active).
Mastership handling has been refactored to generate P4Runtime election IDs that
are compatible with the mastership preference decided by the MastershipService.
GeneralDeviceProvider has been re-implemented to support in-order
device event processing and to reduce implementation complexity. Stats polling
has been moved to a separate component, and netcfg handling updated to only
depend on BasicDeviceConfig, augmented with a pipeconf field, and re-using the
managementAddress field to set the gRPC server endpoints (e.g.
grpc://myswitch.local:50051). Before it was depending on 3 different config
classes, making hard to detect changes.
Finally, this change affects some core interfaces:
- Adds a method to DeviceProvider and DeviceHandshaker to check for device
availability, making the meaning of availability device-specific. This is needed
in cases where the device manager needs to change the availability state of a
device (as in change #20842)
- Support device providers not capable of reconciling mastership role responses
with requests (like P4Runtime).
- Clarify the meaning of "connection" in the DeviceConnect behavior.
- Allows driver-based providers to check devices for reachability and
availability without probing the device via the network.
Change-Id: I7ff30d29f5d02ad938e3171536e54ae2916629a2
Includes also various improvements to the p4vm scripts, such as:
- Choose to build VM with Ubuntu 16.04 or 18.04 (experimental)
- Allow users to specify version of protobuf and grpc to use
- Avoid building protobuf and grpc if already installed in the system
- Install Bazel 0.22
Also:
- Remove check for invalid group member weights (now PI always returns
members with weight 1)
- Re-compiled all P4 programs and fixed missing padding in controller
packet headers
Change-Id: I0e672fcebbaba63354c749f0c774af251f3cbc6c
The new client API supports batching and provides detailed response for
write requests (e.g. if entity already exists when inserting), which was
not possible with the old one.
This patch includes:
- New more efficient implementation of P4RuntimeClient (no more locking,
use native gRPC executor, use stub deadlines)
- Ported all codecs to new AbstractCodec-based implementation (needed to
implement codec cache in the future)
- Uses batching in P4RuntimeFlowRuleProgrammable and
P4RuntimeGroupActionProgrammable
- Minor changes to PI framework runtime classes
Change-Id: I3fac42057bb4e1389d761006a32600c786598683
- Bumped version of protobuf to 3.6.1.3 (includes fix for Bazel 0.22)
- Removed all protobuf and grpc dependencies from deps.json. Instead,
depends solely on what's provided by the external grpc and protobuf
workspaces.
- Use OSGi-wrapped protobuf and grpc JARs built with Bazel for runtime
- Add missing netty-related bundles to onos-thirdparty-base (required
by grpc)
Note, build with Bazel 0.22 is still broken because of
osgi_java_library.bzl, unless the following build arg is used:
build --incompatible_string_is_not_iterable=false
It seems the error is caused by dead code in osgi_java_library.bzl
that should be removed.
Change-Id: I749f1de25902bf9df5242444380f7224bc99b4b5
