A sizable number of tests call pg_start() to get the packets flowing and then
immediately expect to have the entirety of the packets gone through.
This works on powerful and unstressed hardware, but fails in beautifully random
ways under load.
This also necessitates the complicated logic of remembering the "zombie captures",
then sleeping for some time before cleaning them up....
The solution is simple: in pg_start(), start the generators, wait till they
all finish, clean up, done.
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: I930e51b7aae39c9841d22dd905a4d13a465a672b
Type: test
(cherry picked from commit 8d829f6c480cdd6536537fc49356baa1878b9570)
Intermittently, a test would start VPP, but no testcases would execute.
This would be more probable apparent during the high load or if there
is another testcase dumping the core at that moment.
Adding the logging to the connection revealed it was the stats socket
connection erroring with error -2. Increasing the deadline
from 3 seconds to 5 minutes has eliminated this error.
Change-Id: I40bd7e642abb9e2aef0238c612e4c34781de5db2
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Type: test
(cherry picked from commit 4f05a8e408cba09057841d97cd5e7da3058836d1)
Rather than only using time-based method of periodically checking
whether the pcap file appeared, first check that the packet generator
has stopped. To make this change fail-safe, have a 5-minute timeout
on this activity, just in case the things go terribly wrong.
Type: test
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: Id16b2802b2de8a4cafb5d9f0a8c9ba62ec89dc32
(cherry picked from commit 3d36f19a0febaed532bd255a150504f7af8f18c2)
This change is designed to help the uninformed find the right way
to run extended tests by using the test-all[-debug] targets.
'make test EXTENDED_TESTS=y' fails to build as it has a dependency
on 'vom-install' which is conveniently included in test-all[-debug].
- clarify test-all[-debug] description and
make test-help description
- Also align indentation of make help output
Type: style
Signed-off-by: Dave Wallace <dwallacelf@gmail.com>
Change-Id: Ief54cc8a5af68c052aacb0d660237c5eb63451b5
(cherry picked from commit 2777ec761514fc0838ad11e6232ad97897663356)
Type: fix
Some cli processes, including configuring an test flow
on an i40e interface consume more than the currently
available stack space.
Signed-off-by: Chenmin Sun <chenmin.sun@intel.com>
Change-Id: I3df53d251cd43286f94647384d6e50a463bad15c
(cherry picked from commit 2fd44a00aa26188ca75f0accd734f21758c199bf)
Fix a day-1 bug, possibly dating back as far as 2002. The zap64() game
involves fetching 8 byte chunks, and clearing octets not to be
included in the key.
That's fine *unless* the 8-byte fetch happens to cross a page boundary
into unmapped or no-access space.
Type: fix
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I4607e9840032257c96ba7387f86c931c0921749d
(cherry picked from commit 7e2cea3d26701ff1d80fda7d8ca907890e3e7baa)
vnet_feature_enable_disable takes sw_if_index, not hw_if_index. If there
is a subinterface created prior to the slave interface is created,
sw_if_index and hw_if_index start to diverge and the problem will happen.
Type: fix
Signed-off-by: Steven Luong <sluong@cisco.com>
Change-Id: I11e1f099378832f83b748526c6cbeb56960fad3c
(cherry picked from commit 1a41a35b27da6921d6d86a9f1ad5f1b46e1185f7)
The non-extern declaration confuses clang linker in debug mode.
The function is defined as inline above anyway.
Type: fix
Fixes: c6215d902f
Change-Id: Ic7e4477631cf0bcfb31ab3f81effe3642dd4223e
Signed-off-by: Benoît Ganne <bganne@cisco.com>
(cherry picked from commit 5b1379be3e25df096d97dcd217965169fc6bb1b2)
otherwise they get installed twice and the reference counting means they are not removed.
This is the same behaviour as IPv4.
Type: fix
Change-Id: I9266e04ccff6ff06a577e85973a2ddbeb9dfc52b
Signed-off-by: Neale Ranns <nranns@cisco.com>
(cherry picked from commit 1ff3c15b3c7607c9b590ad44d18dea5eb1cb8c4e)
they can use the 'auto' adj for all traffic
Type: fix
Change-Id: Id2b9557683252a94badc8f9dfab5f7b2ae26f1ee
Signed-off-by: Neale Ranns <nranns@cisco.com>
(cherry picked from commit da0e7497ca972f3219352d884b5c51e455503dbb)
If VPP_EXTRA_CMAKE_ARGS is set, its content will be
appended to the vpp cmake command cli
Type: feature
Change-Id: I825d4239e62b0a2fb70a652f0671f6c559630aad
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
(cherry picked from commit 29736540335fb983f472457883e9fefde61bd913)
The old code modified the node next array prior to obtaining the thread
barrier. Then it updated the runtime node data, and upon barrier release
caused reforking of each worker thread. The reforking clones the main
thread nodes and reconstructs the runtime node structure. This cloning
is not 100% "deep" in the sense that the node next array is
shared (i.e., only the pointer is copied). So prior to the barrier being
obtained the node's next array is being changed while workers are
actively using it (bad). Treating the node next array as read-only in
the workers and sharing it is a decent optimization so instead of trying
to fix that just move the barrier a little earlier in the process to
protect the node next array as well.
This was tripping an assert in next frame ownership change by way of the
ip4-arp node. The assert verifies that the node's next array length is
equal to the runtime next node count. The race above was lost and the
node next array data was updated in the main thread while the arp code
was still executing in a worker.
This was being hit when many arp requests were being sent from both ends
of a tunnel during which the add next node function was called, which
often led to an assert b/c the next node array was out of sync with the
runtime next node count.
- PS#2 update - move barrier sync to just above code that modifies state.
Ticket: VPP-1783
Type: fix
Signed-off-by: Christian E. Hopps <chopps@chopps.org>
Change-Id: I868784e28f994ee0922aaaae11c4894a3f4f1fe7
Signed-off-by: Christian E. Hopps <chopps@chopps.org>
(cherry picked from commit d3122ef4ecfa9a515cc39c1632d29e43fa771b2a)
Prints the interior node vector rate, rx / tx / drop rates
Type: feature
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I57130db0f99e852a8498aa90d01e52f7ac33dcc9
(cherry picked from commit ac78f8a902fc61465edf657f7c7da7ff575210c8)
In bond RX quad loop, when all packets within the frame have the same incoming
interface, we cannot skip calling bond_update_next because that function calls
vnet_feature_next() to update the b->current_config_index. The next node needs
the correct b->current_config_index to work with.
Type: fix
Signed-off-by: Steven Luong <sluong@cisco.com>
Change-Id: I3d8b3d4e0f95490f406fae7638f0c43c301ce664
(cherry picked from commit 71e5b4710258376873c62428cb4a81b2a650fc26)
Allow for setting the maximum number of generated packets to be included
in the frame passed to next nodes. This is very important for testing
code which may be susceptible to multi-frame vs single-frame bugs (e.g.,
code that is doing re-ordering where packets may be buffered between
frames).
Update:
- remove redundant packet "rate" option.
- reduce n_max_frame to u32 as that's what pulled from the CLI.
Type: feature
Signed-off-by: Christian E. Hopps <chopps@chopps.org>
Change-Id: Ie362bbb110b2cf01d9f65c559bbe9101e17b7fdc
Signed-off-by: Christian Hopps <chopps@labn.net>
(cherry picked from commit 87d7bac5cf2ebdc7820e1edaadc2cc3b6d111cf2)
If no Linux PCI driver module is loaded, then the driver_name in the PCI
info struct is NULL. This can triggers crash when checking driver name
eg. in vlib_pci_device_open().
Default to "<NONE>" as driver name, which should never match.
Type: fix
Change-Id: I9e69889a7566467bd8220b92bbbaa72ada957257
Signed-off-by: Benoît Ganne <bganne@cisco.com>
(cherry picked from commit 0eae2bb1f1199f7dcb6a8c62b1ea612ed9ee4ae1)
In a rare event, after the vhost protocol message exchange has finished and
the interface had been brought up successfully, the driver MAY still change
its mind about the memory regions by sending new memory maps via
SET_MEM_TABLE. Upon processing SET_MEM_TABLE, VPP invalidates the old memory
regions and the descriptor tables. But it does not re-compute the new
descriptor tables based on the new memory maps. Since VPP does not have the
descriptor tables, it does not read the packets from the vring.
In the normal working case, after SET_MEM_TABLE, the driver follows up with
SET_VRING_ADDRESS which VPP computes the descriptor tables.
The fix is to stash away the descriptor table addresses from
SET_VRING_ADDRESS. Re-compute the new descriptor tables when processing
SET_MEM_TABLE if descriptor table addresses are known.
Type: fix
Ticket: VPP-1784
Signed-off-by: Steven Luong <sluong@cisco.com>
Change-Id: I3361f14c3a0372b8d07943eb6aa4b3a3f10708f9
(cherry picked from commit 61b8ba69f7a9540ed00576504528ce439f0286f5)
gid_ip4_table_t's and gid_ip6_table_t's are allocated from pools. They
MUST NOT be listed on the clib_all_bihash list to avoid dangling
references.
Switch to the clib_bihash_init2 API, which has the required knob.
Type: fix
Ticket: VPP-1788
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I49a17e937922c3af2e1c46b24e20883af51584a8
There is no bt->samples for this test, do not use it.
Type: fix
Change-Id: I2090290887bc5c0b5cdb0561cf2bf72a87781089
Signed-off-by: Benoît Ganne <bganne@cisco.com>
(cherry picked from commit b0a7c484eec9a813751e6e3fa71a9955ad5f0f74)
ACL tests use random port number in the tests.
A port number 6081 causes the decode in scapy
to consume some of the Raw payload into GENEVE
encoding, which breaks the test.
Solution: bring up the lower range of random
port to 16384, so that it does not touch any
of the well known ports.
Type: test
Change-Id: I022660d8ec147857924b436f1871b0b5ddcf4c47
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
(cherry picked from commit ec574ff9129a7cc4282916d2a989e88d78aaff60)
- set msgid to 0 not random.
- allow for no DH in ESP child SA
Ticket: VPP-1781
Type: fix
Signed-off-by: Christian E. Hopps <chopps@chopps.org>
Change-Id: Ibe26009d38f444eeaec5b042097f145d161c7672
(cherry picked from commit 0e182c5b1d27139764dca7059c9c91be8387977a)
