There is no valid reason to have it in the p4rtmeterprogrammable:
- some devices cannot guarantee r/w symmetry
- meters can be only modified
- removal is a modify with default values
Change-Id: I6d859f2d65195f3e7068390fee5e3a943972cac5
There is no need to further process meters default
config in ONOS, there will not be any trace in the
ONOS stores. Filtering out in advance allows to save
memory and time.
Change-Id: I57f598aba3f2ba32923e8170f6c47f9efe27edd4
- Code clean up (unused code, unuseful comments)
- Remove deprecated internal APIs
- Prevent the ejection of the meter pollers
- Prevent the ejection of the mf pollers
- Fix unproper filter of device events
- Fix delete on store which updated existing meters with dummy value
- Fix NPE in TofinoMeterProgrammable caused by default config
- Update unit tests
Change-Id: Ib2767e3ab3cf146693e61b7e1890419c9743d521
(cherry picked from commit a770879a950d1cc985db1a659da701551700e886)
This is achieved by implementing device specific methods to verify if
ONOS store meters and values read from the devices are similar
Change-Id: I95b6a2c728536f08b47ce9d0d30d1b8888a353d7
- 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
This is achieved by translating SIMPLE next objective into
INDIRECT groups. By default SELECT groups are always used
which has as side effect the creation of action profile groups
with the maxGroupSize derived from the action profile model.
Instead, PiGroupTranslator sets always to 1 the maxGroupSize
of action profile groups derived from a INDIRECT groups which
allows us to achieve a better scale for target devices pre-allocating
memory according to the maxGroupSize.
Change-Id: I7079a99ca9a7474eafae7f258da06770453b05f9
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
A default entry according to the P4RT spec should be reset to its original value
and not removed. The client can send a specially crafted write request with action field
unset to reset default actions to the original value
Change-Id: I451a3be395b212e14ae8eaf060cc048500705091
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
Default and Table mirrors were using the same name for their internal EC map.
This was leading to empty EC maps in the standby nodes.
Change-Id: I575dfbf5ba5339f8c94c4e5ed218887a11f14d36
- BngProgrammable interface moved to ONOS core
- BngProgrammable implementation in fabric pipeliner
Change-Id: Ia020d19f305d8819eef7f70453b14cb00fd31af8
(cherry picked from commit 8fd75e7352d12c9ad90b8461a9550d8f7e1b263d)
We achieve this by creating a special mirror to store the original
default entries as specified in the P4 program. Applications can modify
the default entry by inserting flow rules with empty selectors. When
removing such flow rule, the default table entry is restored to the
original one as stored in the mirror.
Change-Id: Ib11a7172ab56be7cbbd23022e4b62ed6b70b6eca
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
Differently from the case where we insert/modify entries, when deleting,
we were not checking the content of the mirror. Now we do, and ignore
the delete operation if the entry is missing from the mirror in the
first place.
Change-Id: Ib7648e3b5e01c87521b1d9a23c88a665092c9707
(cherry picked from commit 1a4f1b288f8c96edab06f2d5fdcb79c55c17b9f6)
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
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
- 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
- Workaround for PI bug that ignores max_group_size
- Use max_group_size and not buckets size when translating groups
Change-Id: Id12a12311b20ca8fb4e785e1c5a4f0f4215d1bbf
Implementations of P4Runtime like Stratum are expected to persist table
entries and other data plane state across reboots.
Change-Id: I4395e9e60b395bfca85c71c9d3bc604a2269a3ce
The fix is simple: when cleaning up inconsistent entries from device,
we update the mirror when the response is received, and not before
sending the request. Otherwise, if delete goes wrong, writes happening
right after reconciliation cycle might find an inconsistent mirror state.
When writing entries (e.g. apply group/flow rule) we keep updating the
mirror before sending the request to handled the case of back-to-back
writes.
Change-Id: I9e1cc5cac3f8746c67e93e2cee17aff78d3f1d7e
This patch also introduces a new driver property flag to indicate
whether a P4Runtime target supports default table entries or not.
Stratum targets built against the current version of p4lang/PI do not.
Change-Id: I1fbb57521516bee99057319ed1695cb05b68ee7c
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
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
Also includes:
- New abstract P4Runtime codec implementation. Currently used for action
profile members/groups encoding/deconding, the plan is to handle all
other codecs via this.
- Improved read requests in P4RuntimeClientImpl
- Removed handling of max group size in P4Runtime driver. Instead, added
modified group translator to specify a max group size by using
information from the pipeline model.
Change-Id: I684bae0184d683bb448ba19863c561f9848479d2
Members can exist outside of a group. Previous naming was ambiguous
about this.
Action group -> action profile group
Action group member -> action profile member
Change-Id: I5097e92253353d355b864e689f9653df2d318230
Includes also other minor changes to gRPC channel creation/connection
process, such as:
- More compact logs showing the gRPC client key
- GrpcChannelController.connectChannel() now returns the same
StatusRuntime exception, no need to wrap it in an IOException
- Wait for channel shutdown after initial connection error
Change-Id: Ib7d2b728b8c82d9f9b2097cffcebd31cac891b27
This patch affects both the P4 pipeline implementation and the
Java pipeconf.
P4 PIPELINE
- Less tables and smarter use of metadata to reduce inter-tables
dependencies and favor parallel execution of tables.
- Removed unused actions / renamed existing ones to make forwarding
behavior clearer (e.g. ingress_port_vlan table)
- Remove co-existence of simple and hansed table. Hashed should be the
default one, but implementations that do not support action profiles
might compile fabric.p4 to use the simple one.
- Use @name annotations for match fields to make control plane
independent of table implementation.
- Use @hidden to avoid showing actions and table on the p4info that
cannot be controlled at runtime.
- First attempt to support double VLAN cross-connect (xconnect table).
- New design has been tested with "fabric-refactoring" branch of
fabric-p4test:
github.com/opennetworkinglab/fabric-p4test/tree/fabric-refactoring
JAVA PIPECONF
This patch brings a major refactoring that reflects the experience
gathered in the past months of working on fabric.p4 and reasoning on its
pipeconf implementation. Indeed, the FlowObjective API is
under-specified and sometimes ambiguous which makes the process of
creating and maintaining a pipeliner implementation tedious. This
refactoring brings a simplified implementation by removing unused/
unnecessary functionalities and by recognizing commonality when possible
(e.g. by means of abstract and utility classes). It also makes design
patterns more explicit and consistent. Overall, the goal is to reduce
technical debt and to make it easier to support new features as we
evolve fabric.p4
Changes include:
- Changes in pipeliner/interpreter to reflect new pipeline design.
- By default translate objective treatment to PiAction. This favors
debuggability of flow rules in ONOS.
- Support new NextObjective’s NextTreatment class.
- Remove lots of unused/unnecessary code (e.g. async callback handling
for pending objective install status in pipeliner as current
implementation was always returning success)
- Gather commonality in abstract classes and simplify implementation
for objective translator (filtering, forwarding, next)
- New implementation of ForwardingFunctionTypes (FFT) that looks at
criterion instance values along with their types (to avoid relying on
case-specific if-else conditions to recognize variants of an FFT)
- Adaptive translation of NextObjective based on presence of simple or
hashed table.
- Support DENY FilteringObjective
Also:
- Fix onos-p4-gen-constants to avoid generating conflicting
PiMatchFieldId variable names.
- Install Graphviz tools in p4vm to generate p4c graphs
- Generate p4c graphs by default when compiling fabric.p4
- Use more compact Hex string when printing PI values
Change-Id: Ife79e44054dc5bc48833f95d0551a7370150eac5
