show vmxnet3 desc may display 5000 lines of output since it has 5 tables. Each
table may have 1000 entries. It would not be very useful to debug problem.
We need filtering capability for the subject show command. We need to be able
to display the descriptor table per interface, per interface per table, and
per interface per table per slot. The latter is the most useful.
tested the following valid combinations
show vmxnet3
show vmxnet3 desc
show vmxnet3 vmxnet3-0/13/0/0
show vmxnet3 vmxnet3-0/13/0/0 desc
show vmxnet3 vmxnet3-0/13/0/0 rx-comp
show vmxnet3 vmxnet3-0/13/0/0 rx-comp 1
show vmxnet3 vmxnet3-0/13/0/0 tx-comp
show vmxnet3 vmxnet3-0/13/0/0 tx-comp 1
show vmxnet3 vmxnet3-0/13/0/0 rx-desc-0
show vmxnet3 vmxnet3-0/13/0/0 rx-desc-0 1
show vmxnet3 vmxnet3-0/13/0/0 rx-desc-1
show vmxnet3 vmxnet3-0/13/0/0 rx-desc-1 1
show vmxnet3 vmxnet3-0/13/0/0 tx-desc
show vmxnet3 vmxnet3-0/13/0/0 tx-desc 1
negative tests and command is rejected
show vmxnet3 abc
show vmxnet3 desc abc
show vmxnet3 vmxnet3-0/13/0/0 abc
show vmxnet3 vmxnet3-0/13/0/0 desc abc
show vmxnet3 vmxnet3-0/13/0/0 rx-comp abc
show vmxnet3 vmxnet3-0/13/0/0 rx-comp 1 abc
Change-Id: I0ff233413496e58236f8fb4a94e493494c20c5cb
Signed-off-by: Steven <sluong@cisco.com>
When using vpp_api_test, there is an undefined symbol error for
format_vlib_pci_addr when vmxnet3_test_plugin.so is loaded.
The cause is due to vlib not included in vpp_api_test. Remove the reference
for vlib.so in vmxnet3_test.
Change-Id: I37c00dfe2f843d99ad6c4fc7af6ed10bac4c2df8
Signed-off-by: Steven <sluong@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 encountered on input.
Change-Id: I41a45213e29de71935afe707889e515037cd081f
Signed-off-by: Steven <sluong@cisco.com>
(cherry picked from commit 8b0995366110ff8c97d1d10aaa8291ad465b0b2f)
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>
(cherry picked from commit 0db9b04cf0f9c892a00988e7a61ae703aa83b721)
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>
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>
If the number of rules within a given partition exceeds the limit,
the split_partition() might get called, in which we calculate
the relaxed mask, create a new partition with that mask and
attempt to reallocate some entries from the overcrowded partition.
The non-TM code was pre-expanding the vector with rules by
the number of rules in the new ACL being applied - which
caused the split_partition() to iterate over the rules
filled with zeroes. Most of the time it is benign, but
if a newly created relaxed partition is such that these
entries can be "relocated", then the code attempts to
do so, which does not end well.
Change-Id: I2dbf3ccd29ff97277b21cdb11c4424ff0915c3b7
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
A copy/paste mistake caused to add padding to the buffer used to send
data.
Change-Id: I04d8dfec4ae195927be1675c5ce8b30230d5b376
Signed-off-by: Marco Varlese <marco.varlese@suse.com>
Handles next_hop_weight, next_hop_preference and next_hop_table_id
properly in vl_api_mpls_tunnel_add_del_t_handler(). Also updated
vpp_api_test and custom_dump handling of related APIs.
Change-Id: I89e211bfa3b9d8ead396b24b3c46b7c7f6511f44
Signed-off-by: John Lo <loj@cisco.com>