- NPE when removing agent listeners
- Don't block netcfg event dispatch thread on GDP
- Avoid unnecessary warn logs during disconnection in GDP
Change-Id: I612f7f7914579eea9ba393e952377a3933d92e8d
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
The P4Runtime client was hanging (deadlock) on a master arbitration
request. As such, all other requests (e.g. table write) were waiting
for the client's request lock to become available.
Apart from fixing those deadlocks, this patch brings a number of
improvements that all together allow to run networks of 100+ P4Runtime
devices on a single ONOS instance (before only ~20 devices)
Includes:
- Asynchrounous mastership handling in DevicHandshaker (as defined in
the P4Runtime and OpenFlow spec)
- Refactored arbitration handling in the P4RuntimeClient
to be consistent with the P4Runtime spec
- Report suspect deadlocks in P4RuntimeClientImpl
- Exploit write errors in P4RuntimeClient to quickly report
channel/mastership errors to upper layers
- Complete all futures with deadlines in P4Runtime driver
- Dump all tables in one request
- Re-purposed ChannelEvent to DeviceAgentEvent to carry also mastership
response events
- Fixed IntelliJ warnings
- Various code and log clean-ups
Change-Id: I9376793a9fe69d8eddf7e8ac2ef0ee4c14fbd198
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
The translation store is now able to maintain mappings between
translated entities and specific instances of a PI entry in the network
(i.e. applied to a device).
The translation service has been refactored to allow users to
learn and forget translated entities.
The refactoring of the P4Runtime driver using this service will be
submitted separatelly.
Change-Id: Iaafd87d90232514853ca0dea0115dbae4f6e7886
Currently bmv2 has a bug while we pulling flows from switch
The switch might crash after we push about 20 flows
Change-Id: Ib4e15ff9256b339eee40595eb438e28a0ce17d8a
Now P4InfoBrowser permits looking up entities by name only, not alias.
Applications should use names as defined in the P4Info when
creating PI IDs (e.g. PiCounterId). However, to avoid breaking support
with BMv2-based pipeline models, when referring to header fields in
tables, i.e. match fields, application should drop any scope identifier
from field names, e.g. "hdr.ethernet.src_addr" should be referred by
applications as "ethernet.src_addr". Such inconsistency will be fixed
with ONOS-7066.
Change-Id: I4d6dceadd233a293b845dba84e62a49680ac930b
- Moved group translation logic to core service
- Removed dependency on KRYO
- Fixed bug where tratments with PI instructions where not supported if
an interpreter was present
- Fixed bug where action profile name was not found during protobuf
encoding (always perform P4Info lookup by name and alias)
- Improved reading of members by issuing one big request for all
groups
Change-Id: Ifcf8380b09293e70be15cf4999bd2845caf5d01e
Implements commonality of all other behaviours. Also, simplified
the implementation of all other P4Runtime behaviours by re-using that.
Change-Id: Ibb25bdd1e0d1c6e8863341df87fa83d4a782b8d9
Data type for the P4Runtime server-specific device ID is uint_64.
We were using int to store it in ONOS.
Change-Id: Ia4624cfc453ccf6b00a690eb9e4e4ad14a7881ec
