Update has been performed only on the scripts and the
executables strictly necessary for the following use cases:
- Build (including Intellij)
- Tests (including Intellij)
- Docker build (including dev and yourkit)
- Upload snapshot (including local)
- Release
Finally, fix the ability to run ONOS using onos-local targets,
stc and docker stc (aka up4 stc env). Last but not least, updated
the azul image to a newer one which exports also the PYTHONENCODING
Change-Id: Ie96f3a9c76dbba83b1fc3896a372f1045d3d7ccc
We provide a new service to facilitate registration of vendor-specific
versions of the Fabric pipeconf (e.g., for Tofino) from third-party
apps. This service is designed such that third-party apps do not need to
depend on internal classes at compile time, such as the behaviour
implementations.
To make this possible, the package structure has been refactored to
separate APIs from implementation.
Change-Id: I487cb806541eb9e6877ebf398a94f057613df8cc
(cherry picked from commit 36d5e7a2337c242e45ee57beacd82bba07a0851d)
- Build with JDK11 and language levels (source and target) are now
enforced in .bazelrc, which depends on our own Java toolchain (defined
in tools/build/bazel/BUILD)
- Easymock bumped to v4.0.2 with support for Java 11 (minor API changes)
- The minimum required Bazel version is now 0.27.*
Change-Id: I0bb6dfe7fc1ea134b5a53dd249c369d58259688c
Some files's scp does not have supporting for ipv6 address.
So, I have added supporting for ipv6 address using scp.
Change-Id: Ie6db5c6988c708e4cec862f6b671dd64b457a69a
Which is much faster to sync since it reduces the scope of the IDE
targets to java libraries. Although, it requires one to execute the
script each time a new app/library is added to the source tree.
Example usage:
onos-gen-bazel-project > .bazelproject
Change-Id: Ia2911a323b66554f4c5ea588573343013c3c739b
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
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
- Allow running up to a given step of install-p4-tools.sh
(e.g. helpful to install only PI)
- Install fabric-p4test deps (ONOS-7656)
- Fix python protobuf libraries not installed
Change-Id: I443edb08f455703ae682e485a89d793a584c30ff
- prep to allow bumping yang tool versin without releasing whole
onos-buck archive
- with this patch,
reverting back from locally patched state
(= undo `patch-yang-libs`)
will be:
$ git checkout -- lib/BUCK tools/build/onos-buck
Change-Id: I06bfccdcfd6b22e2252b5c9dc145cece26058841
Among other things, build now is not based on the upstream version of
onos-setup-p4-dev, but on the local one.
Change-Id: I270a324152a9349d6a9989aa8b5a38b45e1856d9
- Adding gNMI dependencies
- Updating PI and BMv2 to build with sysrepo support
- Building simple_switch_grpc with Thrift server
Change-Id: Ida69d80353652174b0bc61a16b6436bf78a2d194
