Age | Commit message (Collapse) | Author | Files | Lines |
|
Using the cli "set interface tx-queue", it is not possible to assign
tx queue to the last worker thread.
The reason is that vdm->first_worker_thread_index is 1. Adding that
to clib_bitmap_last_set (bitmap) exceeds vdm->last_worker_thread_index
when the CLI specifies the last worker thread.
Also make the threads argument optional to enable user to unbind a queue
from any thread.
Type: fix
Signed-off-by: Steven Luong <sluong@cisco.com>
Change-Id: I796259c20f571289c8f5a97b9418caf452d0ab3d
|
|
Type: improvement
set interface tx-queue tap1 queue 2 threads 1-2
show hardware-interfaces tap1
Name Idx Link Hardware
tap1 2 up tap1
Link speed: unknown
RX Queues:
queue thread mode
0 vpp_wk_1 (2) polling
TX Queues:
queue shared thread(s)
0 no 0
1 no 1
2 yes 1-2
3 no 3
4 no 4
Ethernet address 02:fe:09:3a:48:ff
VIRTIO interface
instance 1
set interface tx-queue tap0 queue 4 threads
show hardware-interfaces tap0
Name Idx Link Hardware
tap0 1 up tap0
Link speed: unknown
RX Queues:
queue thread mode
0 vpp_wk_0 (1) polling
TX Queues:
queue shared thread(s)
0 no 0
1 no 1
2 no 2
3 no 3
4 no
Ethernet address 02:fe:03:6a:66:fc
VIRTIO interface
instance 0
Change-Id: I6154476ec9ff0b14287098529c88a14b779371a5
Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
|
|
Type: feature
Change-Id: I325257454df1cc22833fa6a1dedd4739d4d5a558
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
It naturally belogns there...
Type: refactor
Change-Id: I05f7ba01103a5e9b3756f1ea69c8cc5d8f26f0a0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
If no pcap filters have ever been configured and we try to enable pcap
capture with a filter, cm->classify_table_index_by_sw_if_index is not
initialized yet.
Type: fix
Change-Id: I2f509c58f9984951b1ad81c1c8ed912cb594fce1
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Type: fix
Change-Id: Iebe2db66af1e769486a117d6284375ce5ffff0b4
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
|
|
Change-Id: I85a463b4ca15baf11e3eb70189f5190ba2585170
Type: refactor
Signed-off-by: Mohammed Hawari <mohammed@hawari.fr>
|
|
Change-Id: Ic977ffe761efc2129c61aec581da5479fe4838da
Type: fix
Signed-off-by: Mohammed Hawari <mohammed@hawari.fr>
|
|
Type: improvement
Change-Id: I4008cadfd5141f921afbdc09a3ebcd1dcf88eb29
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Add lookup/get/set API calls to manage both PCAP and Trace
filtering Classifier tables.
The "lookup" call may be used to identify a Classifier table
within a chain of tables taht matches a particular mask vector.
For efficiency, this call should be used to determine to which
table a match vector should be added.
The "get" calls return the first table within a chain (either
a PCAP or the Trace) set of tables. The "set" call may be
used to add a new table to one such chain. If the "sort_masks"
flag is set, the tables within the chain are ordered such that
the most-specific mask is first, and the least-specific mask
is last. A call that "sets" a chain to ~0 will delete and free
all the tables with a chain.
The PCAP filters are per-interface, with "local0", (that is,
sw_if_index == 0) holding the system-wide PCAP filter.
The Classifier used a reference-counted "set" for each PCAP
or trace filter that it stored. The ref counts were not used,
and the vector of tables was only used temporarily to establish
a sorted order for tables based on masks. None of that
complexity was actually warranted, and where it was used,
the same could be achieved more simply.
Type: refactor
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: Icc56116cca91b91c631ca0628e814fb53f3677d2
|
|
Type: refactor
Change-Id: I077110e1a422722e20aa546a6f3224c06ab0cde5
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: refactor
Change-Id: Ie67dc579e88132ddb1ee4a34cb69f96920101772
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
ethernet dataplane loads MAC addresses as 64-bits loads for efficiency.
We must make sure it is valid, especially for the vector of secondary
MACs.
Type: fix
Change-Id: I851e319b8a973c154e85ff9f05f3b8e385939788
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
This is part of bigger refactor.
Type: refactor
Change-Id: I6fc2c0a1e2d217a70952901bcf775b8485bd3c20
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: improvement
- cache the values form the BD on the input config to avoid loading
- avoid the short write long read on the sequence number
- use vlib_buffer_enqueue_to_next
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I33442b9104b457e4c638d26e9ad3bc965687a0bc
|
|
This patch adds the RSS steering queues set interface, and it's
implementation in DPDK device:
/* Interface to set rss queues of the interface */
typedef clib_error_t *(vnet_interface_rss_queues_set_t)
(struct vnet_main_t * vnm, struct vnet_hw_interface_t * hi,
clib_bitmap_t *bitmap);
This patch also introduces a command line to set the RSS queues:
set interface rss queues <interface> <list <queue-list>>
To display the rss queues, use "show hardware-interfaces"
Below is the example to configure rss queues for interface Gig0:
vpp# set interface rss queues Gig0 list 0,2,4-7
vpp# show hardware-interfaces brief
Name Idx Link Hardware
VirtualFunctionEthernet18/1/0 1 down VirtualFunctionEthernet18/1/0
Link speed: unknown
RSS queues: 0 2 4 5 6 7
local0 0 down local0
Link speed: unknown
vpp#
Users can also configure the rss queues on a dpdk interface in
startup.conf:
dpdk {
dev 0000:18:01.0 {
rss-queues 0,2,5-7
}
}
Type: feature
Signed-off-by: Chenmin Sun <chenmin.sun@intel.com>
Change-Id: I1835595a1c54016a84eabee9fd62ce137935385d
|
|
Type: fix
Change-Id: I2b6b7b6f28cbf7accf883743e390b0031dd13bbb
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Type: fix
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Ibad744788e200ce012ad88ff59c2c34920742454
|
|
Type: improvement
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I2e53fa85a0b4082666f57a3a58a09c04ae2001b5
|
|
Type: fix
Change-Id: Iab99bc1f6c309fae6eaa714b484274fe7072a4cb
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Provide a minimal trace [ip4/ip6 src/dst address] for dropped pkts
when the user specifies "trace add error-drop XXXX", but does not
trace pkts from the original input node.
This is a wireshark dissector problem. Packets thrown at error-drop
may be well-formed, or not. VPP must not crash, no matter what.
The minimal trace capture and decode could be enhanced. Anyone
interested in doing that must consider all of the corner-cases
involved. This version should be at least somewhat useful.
Note that "pcap trace drop ..." - and the packet generator - seem like
the right tools to use when researching more complex issues.
Type: improvement
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I961ca133980ffa2a1e5707879a443b21442ed894
|
|
"classify filter trace ... " and "classify filter pcap ..." are
mutually exclusive.
vnet_pcap_dispatch_trace_configure needs to check for
set->table_indices == NULL.
Type: fix
Ticket: VPP-1827
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I43733364087ffb0a43de92e450955033431d559d
|
|
Type: refactor
currently vnet_classify.h is included in ip.h where it's not required.
Change-Id: Id55682637601655aa2edda681536a979c8e323bd
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Someone much more knowledgeable than I wrote:
For L3 IP forwarding, any VLAN tags on a packet must be exact
match to a sub-interface which means both outer and inner VLAN
tag IDs must be exact-matched to specific values defined of that
sub-interface. Without exact match on a L3 sub-interface, VPP
has no mechanism to know what VLAN tags to use for packet output,
such as ARP request packets or IP packets, on that sub-interface.
Thus, sub-interface with "inner-dot1q any" is not an exact match
sub-interface by definition since no match is present on inner
tag.
While in the area, fix a memory leak that would ensue on poorly
configured interfaces.
Change-Id: I8d17a96dbca3e3724c297ecc935ca61764e6ce2e
Type: fix
Signed-off-by: Jon Loeliger <jdl@netgate.com>
|
|
This fix was first made in
commit fdea5c6a00b74971dbb1b7ec4e25839a871006ca
but was subsequently lost in
commit 053204ab039d34a990ff0e14c32ce3b294fcce0e
Added unit test for setting VTR on a non-sub-interface to
help ensure no future regressions of this ability.
Type: fix
Change-Id: I71ce2684fb72383741455829ae2d397ea2e95eae
Signed-off-by: Jon Loeliger <jdl@netgate.com>
|
|
Type: feature
New callback vnet_hw_interface_add_del_mac_address().
Add or delete secondary MAC addresses on a hardware interface.
This will allow packets to be processed which have a destination
MAC address other than the primary programmed MAC address without
needing to put the device into promiscuous mode.
Change-Id: I6beecbcb8932fc1fe45b567f76fa3706feefae2c
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
Type: feature
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I79b216d2499df143f53977e5b70382f6f887e0bc
|
|
Use a single vnet_pcap_t in vlib_global_main, specifically to support
unified tracing
Update sphinx docs, doxygen tags
Type: refactor
Ticket: VPP-1776
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Id15d41a596712968c0714cef1bd2cd5bc9cbdd55
|
|
The 9af7e2e87e used a comparison that fd is >= 0 to check that
the pcap needs closing. While the pcap_close() function does
reset the file descriptor to -1, the freshly initialized structure
has it equal to 0.
This causes the VPP to close stdin if the packets are being seen
on pg interface without the capture file being opened.
This triggers the vpp attempting to read from STDIN
(another bug), which results in running out of memory.
Change-Id: I11d61422701500a9b3e0dd52d59383f297d57f54
Type: fix
Fixes: 9af7e2e87e
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
See .../src/vnet/classify/trace_classify.h for the business end
of the scheme.
It would be best to hash pkts, prefetch buckets, and do the primary
table lookups two at a time. The inline as given works, but perf
tuning will be required. "At least it works..."
Add "classify filter" debug cli, for example:
classify filter mask l3 ip4 src dst \
match l3 ip4 dst 192.168.2.10 src 192.168.1.10
Add "pcap rx | tx trace ... filter" to use the current classify filter chain
Patch includes sphinx documentation and doxygen tags.
Next step: device-driver integration
Type: feature
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: I05b1358a769f61e6d32470e0c87058f640486b26
|
|
Separate debug CLI arg parsing from the underlying action
function. Fixes a number of subtle ordering dependencies, and will
allow us to add a binary API to control the feature at some point in
the future.
Type: refactor
Ticket: VPP-1770
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Id0dbeda06dad20e756c941c691e2088ce3c50ec7
|
|
when use pcap cli to capture pcakets into two files rx01.pcap && rx02.pcap,
the first time:
1)pcap rx trace on max 100 intfc any file rx01.pcap
2)......the process of capture data to buffer......
3)pcap rx trace off
the second time:
4)pcap rx trace on max 100 intfc any file rx02.pcap
5)......the process of capture data to buffer......
6)pcap rx trace off
the pcap_write function bug in this two lines
pm->n_packets_captured = 0;
if (pm->n_packets_captured >= pm->n_packets_to_capture) referring to calling pcap_close()
will result in that the twice pcap cli both writes the packets
into rx01.pcap, but nothing into rx02.pcap. Beside, the rx02.pcap
file will not be created.
solution: separate the pcap_close() out of pcap_write()
Change-Id: Iedeb46f9cf0a4cb12449fd75a4014f95f3bb3fa8
Signed-off-by: Jack Xu <jack.c.xu@ericsson.com>
|
|
Provide default packet_to_capture value. Display interface name
correctly for "pcap tx/rx trace status".
Type: fix
Signed-off-by: John Lo <loj@cisco.com>
Change-Id: I7064d0dbea236a9aff68bba7fbaf2c4a73b16c6f
Signed-off-by: John Lo <loj@cisco.com>
|
|
leak-check { <any-debug-cli-command-and-args> }
Hint: "set term history off" or you'll have to sort through a bunch of
bogus leaks related to the debug cli history mechanism.
Cleaned up a set of reported leaks in the "show interface" command. At
some point, we thought about making a per-thread vlib_mains vector,
but we never did that. Several interface-related CLI's maintained
local static cache vectors. Not a bad idea, but not useful as things
shook out. Removed the static vectors.
Change-Id: I756bf2721a0d91993ecfded34c79da406f30a548
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
BRIDGE_DOMAIN_DUMP, CONTROL_PING, CONTROL_PING_REPLY, and show interface CLI
Change-Id: I2927573b66bb5dd134b37ffb72af0e6676750917
Signed-off-by: Steven Luong <sluong@cisco.com>
(cherry picked from commit 15c31921a628c5500cbed2ebc588d7ddbaa970a3)
|
|
pcap rx trace on max 100 intfc tap0
then
pcap rx trace status
Displays "local0" instead of "tap0" due to a typo in
pcap_trace_command_internal(...).
Change-Id: Id2de6a24174aac24d9051b7404f01edc806a6573
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ia2be56e198c960788430705b356170f8cc12c450
Signed-off-by: Jack Xu <jack.c.xu@ericsson.com>
|
|
Moved code to the ethernet input node, and the interface output
path(s). Since we no longer skip ethernet-input, there's no reason
for device drivers to know anything about pcap rx tracing, etc.
Change-Id: I08d32fb1b90cbee1bd4f609837d533e047b36fa4
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I15ff191ee8724a3354c074db590472db05e0652e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Before
------
DBGvpp# sh int rx-mode
sh int rx-mode
Thread 1 (vpp_wk_0^@):
node vmxnet3-input:
vmxnet3-0/b/0/0 queue 0 (polling)
Thread 2 (vpp_wk_1^@):
node vmxnet3-input:
vmxnet3-0/13/0/0 queue 0 (polling)
DBGvpp#
After
-----
DBGvpp# sh int rx-placement
sh int rx-placement
Thread 1 (vpp_wk_0):
node vmxnet3-input:
vmxnet3-0/b/0/0 queue 0 (polling)
Thread 2 (vpp_wk_1):
node vmxnet3-input:
vmxnet3-0/13/0/0 queue 0 (polling)
DBGvpp#
Change-Id: I5910d502757054c3942fac9d20c5104e95fc6b56
Signed-off-by: Steven <sluong@cisco.com>
|
|
Change-Id: I085615fde1f966490f30ed5d32017b8b088cfd59
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Change-Id: I9228ce29e9d2fc862a2d076b4072bcdd728d6dd1
Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
|
|
with ip direct broadcast enable a packet to the interface's
subnet broadcast address with be sent L2 broadcast on the
interface. dissabled, it will be dropped. it is disabled by
default, which preserves current behaviour
Change-Id: If154cb92e64834e97a541b32624354348a0eafb3
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
This patch separates setting of hardware interfaec and software
interface MTU. Software MTU is L2 payload MTU (i.e. not including L2
header). Per-protocol MTU for IPv4, IPv6 and MPLS can also be set.
Currently only IP4, IP6 are enabled in adjacency / rewrite code.
Documentation in src/vnet/MTU.md
Change-Id: Iee2fd6f0bbc8210748dd8e073ab9fab87d323690
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
the ip4-dhcp-client-detect feature MUST run prior to nat44-out2in, or
inbound dhcp broadcast packets will be dropped. Certain dhcp servers
answer lease renewal dhcp-request packets with broadcast dhcp-acks, leading
to unrecoverable lease loss.
In detail, this constraint:
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa"),
};
doesn't get the job done:
ip4-unicast:
[17] nat44-out2in
[23] ip4-dhcp-client-detect
[26] ip4-not-enabled
Add a proper constraint:
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa",
"ip4-dhcp-client-detect"),
};
and the interface feature order is OK, at least in this regard:
ip4-unicast:
[17] ip4-dhcp-client-detect
[18] nat44-out2in
[26] ip4-not-enabled
We need to carefully audit (especially) the ip4-unicast feature arc,
which has [gasp] 37 features on it!
Change-Id: I5e749ead7ab2a25d80839a331de6261e112977ad
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
interface)"
This reverts commit 70083ee74c3141bbefb185525315f1b34497dcaa.
Reverting as this patch is causing following crash:
0: /home/damarion/cisco/vpp3/build-data/../src/vnet/devices/devices.h:131 (vnet_get_device_input_thread_index) assertion `queue_id < vec_len (hw->input_node_thread_index_by_queue)' fails
Aborted
Change-Id: Ie2a365032110b1f67be7a9d832885b9899813d39
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I98bd454a761a1032738a21edeb0fe847e801f901
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
Change-Id: Iae5532c3d53e208831f3b2782242d9e59d367087
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- setting MTU on an interface updates the L3 max bytes too
- value cached in the adjacency is also updated
- MTU exceeded generates ICMP to sender
Change-Id: I343ec71d8e903b529594c4bd0543f04bc7f370b3
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|