DPDK has switched to dynamic logging for initialization (since 18.05).
Don't generate config for unused options.
Change-Id: I3f1a5b3b8bee38abc9d0654737b59368646ed0fa
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The rte_device is use as a base type of all DPDK devices.
It is not valid to use container_of to find PCI information
unless the bus of the rte_device is pci. Otherwise, the
pointer is looking at some other data, which may or may not
be zero.
This change introduces a helper function to get rte_pci_device
pointer. If device is on PCI bus it returns pointer to
rte_pci_device info, otherwise it returns NULL.
Change-Id: Ia7446006bb93a7a54844969f3b3dd3b918890dfd
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
And improve the robustness of the ethertype whitelist test coverage
Change-Id: I64fe3a25208dbc619ae5cd6404f6122e69394a38
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
20e6d36b has moved the calculation of the l3_hdr_offset into the determine_next_node()
function, with the assumption that the current_data in the buffer is at
the L3 header. This is not the case for the single loop fastpath,
where the vlib_buffer_advance() call is made after the call to
determine_next_node(), as a day1 behavior. As a result - that path
incorrectly sets the l3_hdr_offset.
Solution: move the vlib_buffer_advance() call to before determine_next_node()
Change-Id: Id5eaa084c43fb6564f8239df4a0b3dc0412b15de
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
(cherry picked from commit 376414f4c3)
An overview of parallel test runs, describing the library used, results
gathering, stdout and stderr handling and how to execute a parallel run.
Change-Id: Ic83cd689751ee46914e3b858b0b24a74b083f99f
Signed-off-by: juraj.linkes <juraj.linkes@pantheon.tech>
when multiple session creating script is ran (via exec) only the first
one actually starts
Change-Id: I0fc36f65795c8921cf180e0b555c446e5a80be45
Signed-off-by: Eyal Bari <ebari@cisco.com>
try harder on output - if there is no descriptor space available, try to free
up some and check again.
make sure we free the buffer if error is encoutered on input.
Change-Id: I41a45213e29de71935afe707889e515037cd081f
Signed-off-by: Steven <sluong@cisco.com>
- Fixed a bug when an error occuring in tearDownClass would not result in
test being marked as failed
- Improved test results reporting in cases when an error occurs in setUpClass
and tearDownClass
- Fixed DEBUG=core when the core is produced in setUpClass or
tearDownClass
- Reworked DEBUG=core to always be handled after all tests have been
executed
- Fixed FAILFAST=1 for parallel test runs
Change-Id: I3e9cd3b97ba6fa802fa0aa2dd7678ff82eee09ec
Signed-off-by: juraj.linkes <juraj.linkes@pantheon.tech>
This fixes the l2BD and ip4 test case failures.
Fixes VPP-1432, VPP-1428, VPP-1430
Change-Id: I48b5c961bab60cc3b39fcd6db47e098c81579480
Signed-off-by: Sirshak Das <sirshak.das@arm.com>
The issue surfaced when developing the tap GSO code, with
an iteration where output path is reliant on
vnet_buffer (b0)->l3_hdr_offset being set correctly in
the input path, during performance testing.
Adding a workaround in the TX path shows that
the issue surfaces only for relatively few packets
during the test (about 100 out of 600000).
Analysis shows the issue arises if the ethernet-input
is handling two untagged packets with different sw_if_index
values - then the accelerated path punts to slow path,
before the setting of the l2.l2_len values is done,
thus resulting in them being 0, and l3_hdr_offset being
the same as l2_hdr_offset, wreaking havoc on TX path.
The solution is to move the l2_hdr_offset calculation
into a place where it is done for all the packets,
and move the l3_hdr_offset calculation into
the determine_next_node() function - as that function is
also the one setting the special-case l2.l2_len value for
tagged packets and moving the current_data for the L2 case.
Change-Id: If728c7715e011930c1887691188c98055bddde67
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Check access rights using effective user/group IDs
Change-Id: I3683258c24bcd7817024bffbd56b54b2f596fdd7
Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>
- better approximate time when test finishes
- move common vcl and sock test code to vcl_test.h
- overall refactor of variable names
Change-Id: I8e6b43fc017cd05a0ddaa3891767a44fb300c09e
Signed-off-by: Florin Coras <fcoras@cisco.com>
active-backup mode is using l2 load balance algo. It should be using
active-backup. Also notice that the output is missing a character.
vpp# create bond mode active-backup
create bond mode active-backup
vpp# sh bond
sh bond
interface name sw_if_index mode load balance active slaves slaves
BondEthernet0 6 xor l34 2 2
BondEthernet1 9 xor l34 1 1
BondEthernet2 10 active-backu l2 0 0
vpp#
Change-Id: If5ed0cc6c25f6c2ddabec15ff6188b34923d38e3
Signed-off-by: Steven <sluong@cisco.com>
Introduce bond_tx_inline which takes lb as a constant for gcc to do the optimization
The number appears a tad better for 256 bytes frame.
with the patch
--------------
Thread 2 vpp_wk_1 (lcore 3)
Time 4.3, average vectors/node 224.00, last 128 main loops 40.00 per node 222.61
vector rates in 8.4836e6, out 1.6967e7, drop 0.0000e0, punt 0.0000e0
Name State Calls Vectors Suspends Clocks Vectors/Call
BondEthernet0-output active 141054 36109824 0 2.51e1 256.00
BondEthernet0-tx active 141054 36109824 0 2.55e1 256.00
TenGigabitEthernet6/0/0-output active 141054 18055469 0 9.43e0 128.00
TenGigabitEthernet6/0/0-tx active 141054 18055469 0 6.97e1 128.00
TenGigabitEthernet6/0/1-output active 141054 18054355 0 9.54e0 127.99
TenGigabitEthernet6/0/1-tx active 141054 18054355 0 7.05e1 127.99
bond-input active 141054 36109824 0 1.76e1 256.00
dpdk-input polling 70527 36109824 0 5.03e1 512.00
ethernet-input active 141054 36109824 0 6.12e1 256.00
ip4-input active 141054 36109824 0 3.26e1 256.00
ip4-lookup active 141054 36109824 0 2.94e1 256.00
ip4-rewrite active 141054 36109824 0 3.27e1 256.00
without the patch
-----------------
Thread 2 vpp_wk_1 (lcore 3)
Time 4.3, average vectors/node 224.00, last 128 main loops 40.00 per node 222.61
vector rates in 8.4443e6, out 1.6889e7, drop 0.0000e0, punt 0.0000e0
Name State Calls Vectors Suspends Clocks Vectors/Call
BondEthernet0-output active 142744 36542464 0 2.51e1 256.00
BondEthernet0-tx active 142744 36542464 0 2.67e1 256.00
TenGigabitEthernet6/0/0-output active 142744 18270813 0 9.19e0 127.99
TenGigabitEthernet6/0/0-tx active 142744 18270813 0 6.98e1 127.99
TenGigabitEthernet6/0/1-output active 142744 18271651 0 9.43e0 128.00
TenGigabitEthernet6/0/1-tx active 142744 18271651 0 7.02e1 128.00
bond-input active 142744 36542464 0 1.76e1 256.00
dpdk-input polling 71372 36542464 0 5.08e1 512.00
ethernet-input active 142744 36542464 0 6.15e1 256.00
ip4-input active 142744 36542464 0 3.23e1 256.00
ip4-lookup active 142744 36542464 0 2.96e1 256.00
ip4-rewrite active 142744 36542464 0 3.28e1 256.00
Change-Id: I9fd43eda3c735cbff680ac6d2f01ecdae81f0eda
Signed-off-by: Damjan Marion <damarion@cisco.com>
The old "sample_plugin" page was stuffed with superceded autotools
build information, so it morphed into an "add a new plugin" page based
on the emacs-lisp plugin generator.
Before sending hate mail about emacs, please *look* at the new
document: you'll find running the plugin generator hard to tell from
running a shell script.
Change-Id: I84da45675e838c05faeca05c8f7be45d8c7bff13
Signed-off-by: Dave Barach <dave@barachs.net>
tested with:
DBGvpp# show node foo
show node: unknown node name: 'foo'
DBGvpp# show node error-drop
node error-drop, type internal, state active, index 543
node function variants:
...
DBGvpp# show node error-drop bar
show node: unknown input 'bar'
Change-Id: I896cee9e60028a189dce83666fa4d32a14983a7b
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
store local/remote addresses + vrf + vni in hash key
store complete decap info in hash value (sw_if_index + next_index +
error)
this removes the need to access the tunnel object when matching both
unicast and mcast.
however for mcast handling it requires 3 hash lookups:
* one failed unicast lookup (by src+dst addrs)
* lookup by mcast(dst) addr .
* unicast lookup (tunnel local ip as dst + pkt's src addr)
where previously it needed 2:
* lookup by src to find unicast tunnel + compare dst to local addr
(failing for mcast)
* lookup by mcast to find the mcast tunnel
Change-Id: I7a3485d130a54194b8f7e2df0431258db36eceeb
Signed-off-by: Eyal Bari <ebari@cisco.com>