- catch errors in the cfgdef tool and abort compilation if a mismatch
is seen
- Fix mismatches in the code discovered by the tool
Change-Id: Icd9a15eb9312bba6c2208b0b2a684062fcdc19c3
Since Stratum persists pipeline config across reboots, the
GeneralDeviceProvider was marking the device available as the device
had a pipeline config set right after the connection open event, but we
had to wait for the periodic PipeconfWatchdog check to mark the pipeline
as READY. Now we trigger a PipeconfWatchdog check after every device
availability change event.
Change-Id: I11a6f52ff5ea5304aa26dbe39786a25055b828aa
Implementations of P4Runtime like Stratum are expected to persist table
entries and other data plane state across reboots.
Change-Id: I4395e9e60b395bfca85c71c9d3bc604a2269a3ce
The netconf device provider always restart scheduled task
even if polling frequency is not actaully changed.
This patch fixed that restart the scheduled task when polling frequency is really changed.
Change-Id: Ib2175e882bf6a22e7934955020c00b092a13a48f
When the next hop moves from [1A,1B] to [1A],
there should be a route on 1B pointing to 1A via spines
Change-Id: I817414fb4e9edf29357fdb5e55675537ff5f0cac
(cherry picked from commit 53eae194a8b66287855483359309597e8df2efa9)
- Fix scenario files to use correct deviceId
- More robust liveness check in bmv2.py
- Use different ports for stratum internal server
- Longer switch startup timeout in bmv2.py
- Ignore number of flow rules when checking summary (make scenario
independent of trellis implementation)
Change-Id: I206e5339d2e78ae9a025caa5ec4862a9d4c24871
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
No need to maintain a separate fork of gnmi when what we need can be
achieved with a simple Bazel rule
Change-Id: I94ce6f617306e8fb68c44ec2a64743996d3c2f38
Some files's scp does not have supporting for ipv6 address.
So, I have added supporting for ipv6 address using scp.
Change-Id: Ie6db5c6988c708e4cec862f6b671dd64b457a69a
The GeneralDeviceProvider works with device IDs with prefix "device:",
which is the same leadership topic prefix used by the Mastership
service. This caused an issue when any app was creating leadership
contests with topic deviceId.toString() (e.g. XConnectManager,
DefaultRoutingHandler, etc), as the resulting leadership events where
picked by the mastership service and propagated, because of the "device:"
prefix.
This patch minimizes the occurrence of such issue by choosing a more
specific leadership topic prefix for the mastership service. However,
the right solution would be to add isolation of leadership contests
between different services/apps.
Change-Id: I333fd9796a66bb4ca04cd2facd337ac57a2947b2
The use of strong consistent counter creates a huge performance overhead.
The semaphore also prevent parallel processing of DHCP packets.
Moving forward, we should replace this with local counter, CRDT, or other less expensive counters.
Change-Id: I4023ae2b6867a3f3ab3675717ce6e9c396580b19
gNMI does not support mastership. This driver allows controlling gNMI
devices without the need of other mastership-oriented protocols (e.g.
P4Runtime).
Change-Id: I300607fbcc99d3f066904a96e55c9cd954d5d0a5
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
