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
Such as mapping from PiMatchFieldId to Criterion.Type. This should not
be required since the only translation happening is from north
(Criterion.Type) to south (PiMatchFieldId).
Change-Id: I204e0bd66b3996fd60bc11d4241e8a0408e11582
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
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
- Use auto-generated BasicConstants
- Implement own pipeliner that maps to table0 (will remove soon
interpreter mapping for index table IDs)
Change-Id: I19fd2091605edc0efbe62134e1ad8e3336089cde
Most notably, we fix a bug in which some nodes were not able to find
pipeconf-specific behaviors for a given device. The problem is not
completelly solved but it's mitigated.
There's a race condition caused by the fact that the GDP updates the cfg
with the merged driver name before advertising the device to the core.
Some nodes might receive the cfg update after the device has been
advertised. We mitigate the problem by performing the pipeline deploy
(slow operation) after the cfg update, giving more time for nodes
to catch up. Perhaps we should listen for cfg update events before
advertising the device to the core?
Also:
- NPE when getting P4Runtime client
- Detect if a base driver is already merged in pipeconf manager
- Longer timeouts in P4Runtime driver and protocol (for slow networks)
- Configurable timeout in P4Runtime driver and GDP
- NPE when adding/removing device agent listeners in P4Rtunime handshaker
- Various exceptions due to race conditions in GDP when disconnecting
devices (by serializing disconnect tasks per device)
- NPE when cancelling polling tasks in GDP
- Refactored PipeconfService to distinguish between driver merge,
pipeconf map update, and cfg update (now performed in the GDP)
- Fixed PipeconfManagerTest, not testing driver behaviours
- Use Guava striped locks when possible (more memory-efficient than maps,
and with strict atomicity guarantees w.r.t. to caches).
Change-Id: I30f3887541ba0fd44439a86885e9821ac565b64c
Includes:
- Use new P4Runtime "v1" package names
- Removed VALID match
- New table entry priority spec (1 is min priority, not 0)
- Fixed p4c-bm2-ss to include arch flag
- Re-compiled P4 programs with more recent p4c (with updated p4info)
Change-Id: I05908f40eda0f0c755009268fd261fb8bcc9be35
This change makes the Basic pipeline compile better with different
compilers. One change is this: the type parameter for a v1model meter
instance cannot be a programmer-defined enum. This is because in P4_16,
enums don't necessarily have underlying bitstring types and the
language doesn't specify that enum members should be assigned a
numerical value in any given way.
Change-Id: Id2b758eb2b6e76aa708c2e03e7a001667efddb3d
This is related to ONOS-7595. In a recent P4Runtime update, it has been
made explicit that tables can support at most 1 direct counter. Hence,
the pipeline interpreter no longer needs to provide a mapping between a
table and one of potentially many counters. If needed, such mapping can
be derived from the pipeline model (i.e. the p4info)
Change-Id: Ibdece52f35a4d187ab9dbeb90f5527b6285e9788
Includes fixes for:
- ONOS-7593: Support for indirect resource Index type
- ONOS-7595: Removed ID from direct resources
- P4Runtime requires unset bits to be 0 in ternary field matches
- Incorrect parsing of flow rule byte counters
- Full entity names in P4Info with top-level control block (fixed only
for basic.p4, other programs need to be re-compiled and PI IDs in
respective pipeconf changed)
Change-Id: Ia19aa949c02e363a550e692915c6d6516a2d13d7
