| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: I94c06b07a39f07ceba87bf3e7fcfc70e43231e8a
Signed-off-by: Damjan Marion <damarion@cisco.com>
Co-Authored-By: Milan Lenco <Milan.Lenco@pantheon.tech>
|
|
System timer of ARMv8 runs at a different frequency than the CPU's.
The frequency is fixed, typically in the range 1-50MHz. It can be
read at CNTFRQ special register.
Change-Id: I6a21a6a9e2df783559df0caec63d5525c2258227
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
|
|
expiry value
This commit addresses two issues:
1) Avoid refilling the timing wheel with stale timers in rare circumstances.
The timing_wheel_advance() may call advance_cpu_time_base() to update the cpu_time_base,
which is used as a starting point for 32-bit offsets of events on the timer wheel.
If the timing_wheel_advance() is not called for a longer period of time,
then advance_cpu_time_base() is called multiple times in a loop.
advance_cpu_time_base() has two parts - the first part adjusting
the base for the existing event, and the second part trying to fill
with the new events from the overflow queue, which now fit into
the 32-bit-sized time window off the new cpu_time_base.
In doing so this second part incorrectly considers the timers which
have just expired (have the time index == w->current_time_index)
to still be unexpired and places them onto the wheel instead of returning
them as expired.
For quick successive executions of timing_wheel_advance() these events
result in a relatively benign late expiry - the newly placed events expire
during the next call to timing_wheel_advance().
If the successive executions of timing_wheel_advance() result in multiple
invocations of advance_cpu_time_base(), the Nth iteration of it may place a stale
event on the timer wheel if the event time index equals to the current time index
(which has been previously purged), while the N+1th iteration of it will trigger
an assert violation on this stale event, resulting in a reboot.
As part of the testing, two test runs were done before and after the change.
Each of the test runs consisted of the following command:
for i in `seq 1 300`; do ./test_timing_wheel validate events 10000 synthetic-time verbose seed $i iter 10000 wait-time 2 max-time 300; done
The test runs completed identically, however they uncovered the following assert failure:
vpp/src/vppinfra/test_timing_wheel.c:225 (test_timing_wheel_main) assertion `min_next_time[0] <= tm->events[i]' fails
This assert is the second issue covered by this commit:
2) Inserting a new element may result in incorrect cached expiry value
The w->cached_min_cpu_time_on_wheel is being updated within timing_wheel_advance() every time
the elements are expired.
However, it is not touched if the new elements are inserted. Assuming current time is "T"
and the cached min cpu time is "T+X", if a new element is being inserted whose expiry time is "T+Y",
and Y is such that Y < X, then the value w->cached_min_cpu_time_on_wheel becomes incorrect
until the next expiry event, during which it is updated. The test catches this transient condition
which results in the asserts seen in the runs above.
The solution is to update the w->cached_min_cpu_time_on_wheel within timing_wheel_insert_helper()
as necessary.
Change-Id: I56a65a9a11cc2a1e0b36937a9c6d5ad10233a731
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
1) tests for RA options
2) memleaks deleteing a ip6_radv_info_t
3) MLD prefix code refactoring
Change-Id: I34db103994bd8fbdbbec50b202d72770dd145681
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Current code wos copying same data twice when length is 16.
Change-Id: I8d935b32f61672aaea9789c097a5083ae8f78cdd
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I49e5ce0aae6e4ff634024387ceaf7dbc432a0351
Signed-off-by: Dave Barach <dave@barachs.net>
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I0ccb337eb0ed50ccc64193533cd816f6e36e6db5
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I9ac04b15440297c154ed1e3fba888915044cb245
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
The idea is to prevent a huge processing burst if, say, the network goes
down 10' for some reason, and so that we don't need to expire 1M timer
sessions on the first call.
The maximum is not an exact value, but a value after which the
expiration process is postponed until the next call.
That way, we don't have to process the same tick twice, nor to unlink
timers once at a time when processing a tick.
The fact that a timer slot could contain many entries should be dealt
with by changing the number of ticks per second.
Change-Id: I892d07f965094102a3d53e7dbf4e6f5ad22d4967
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
|
|
In the CLI parsing of 'set interface ipsec key garbage', the token
'garbage' enters the processing code for the <key>. This enters
unformat_hex_string(..) which looks through the input for 0-9,a-f and
drops out if a non-hex digit is encountered. The problem is that it
returns 1, indicating that input has been processed, but in this case,
no characters have been removed from the input string. This causes the
calling function to go to the top of the loop and process the next
token, which is now the same token and gets stuck in an infinite loop.
Updated unformat_hex_string(..) to return 0 if no characters were
processed.
This funcitons is used in multiple CLI Commands, but most have token
that preceeds the hex string. Since the token is stripped, the CLI
command is able to avoid an infinte loop.
Change-Id: Ib54f04f23c4d3563ec57a2450982d3648cedec0e
Signed-off-by: Billy McFall <bmcfall@redhat.com>
|
|
to be used for node statistics
Also fix tw_timer_stop() description
Change-Id: I84b529e330c4534fd55487e7e2b8b089ee68ca11
Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
|
|
Change-Id: Iefffcf7843dc11803d69a875a72704a2543911a1
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I5499dd6b768425a56936afae50bd578620c83d30
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I2575d780d19e12ddf8a77e5596e5d7cc3dbf4233
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
- IPv[46] mfib tables with support for (*,G/m), (*,G) and (S,G) exact and longest prefix match
- Replication represented via a new replicate DPO.
- RPF configuration and data-plane checking
- data-plane signals sent to listening control planes.
The functions of multicast forwarding entries differ from their unicast conterparts, so we introduce a new mfib_table_t and mfib_entry_t objects. However, we re-use the fib_path_list to resolve and build the entry's output list. the fib_path_list provides the service to construct a replicate DPO for multicast.
'make tests' is added to with two new suites; TEST=mfib, this is invocation of the CLI command 'test mfib' which deals with many path add/remove, flag set/unset scenarios, TEST=ip-mcast, data-plane forwarding tests.
Updated applications to use the new MIFB functions;
- IPv6 NS/RA.
- DHCPv6
unit tests for these are undated accordingly.
Change-Id: I49ec37b01f1b170335a5697541c8fd30e6d3a961
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ib0144ba3a9a09971d3946c932e8fed6d5c1ad278
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I55dad7b5cfb3d38c22b1105f7d2d61e7449410ea
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
Damjan Marion
Gabriel Ganne
Andrew Yourtchenko
Neale Ranns
Dave Barach
Florin Coras
Billy McFall