summaryrefslogtreecommitdiffstats
path: root/src/vlib/node.c
AgeCommit message (Collapse)AuthorFilesLines
2020-09-15vlib: fix call to vlib_get_node_by_nameBenoît Ganne1-1/+4
Type: fix Change-Id: I1b4f52e186165b04db5bd5f11058dc77b647bc94 Signed-off-by: Benoît Ganne <bganne@cisco.com> (cherry picked from commit 268e3b647733807dbecf402fcebedceff4c85544)
2020-09-05vlib: vlib_get_node_by_name fails via APINathan Skrzypczak1-2/+1
Type: fix Calling vlib_get_node_by_name via the VPE api doesn't work due to hash weirdness. Haven't gotten around the real cause of this. But this fixes it. Change-Id: I89f95dba2bcd9573b8f1f435e063e9dd57f9ca93 Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
2020-06-12vlib: node recyling and node deletion missing triggering graph node syncSteven Luong1-27/+1
When recycling a graph node vnet_register_interface, it is missing an explicit call to vlib_worker_thread_node_runtime_update(). However, there is an implicit call to vlib_worker_thread_node_runtime_update() via vnet_sw_interface_set_flags_helper() if it enables a new feature on the interface for the first time. But that implicit call is not guaranteed. For example, if an interface is created, deleted, and created, then it may skip the implicit call to vlib_worker_thread_node_runtime_update(). When that happens, the graph nodes on thread 0 are not sync'ed to the worker threads. So the worker thread's graph nodes are out of sync momentarily with the main thread's graph nodes until some other event happens which calls for a sync is needed. During this window, the worker thread's graph node is vulnerable and may experience a crash. When deleting a graph node, we never trigger a sync to the worker thread. A patch was committed 3 years ago via https://gerrit.fd.io/r/c/vpp/+/7523 to fix a show run crash. In hindsight, the approach taken by 7523 is not orthogonal. While at it, let's fix it right for both issues with a call to vlib_worker_thread_node_runtime_update() in the appropriate place and remove 7523. Type: fix Ticket: VPPSUPP-86 Fixes: gerrit 7523 / 19e9d954bd9eb4f04d48640d6540198e84ef65d7 Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: Ic9472bd2d3a212dbfeceb526506ed0400983a142
2020-06-08vlib: Coverity fixDave Barach1-1/+1
Fix a nit warning: we're not likely to create a vlib process with more than 4gb of stack. Type: fix Ticket: VPP-1888 Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I8bc7f64287c2802b0c286ce3d04443ac723a9a33
2020-05-20vlib: mmap process stacksDamjan Marion1-34/+25
Instead of allocating stack from the main heap, this patch mmaps stack memory together with guard page. This aproach reduces main heap usage, and stack memory is prefaulted on demand, so bigger process stacks will have zero impact on memory usage as long as stack memory is not needed for real. In addition, it fixes issue with systems which have bigger default page size (observed with 65536). Type: improvement Change-Id: I593365c603d4702e428967d80fd425fdee2c4a21 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-11-04vlib: fix for vlib_node_add_next_with_slotChristian Hopps1-1/+10
- vlib_node_add_next_with_slot was not cleaning the old next node references to the given slot when replacing it with new next node. This mostly worked until one tried to set the slot to a previously (but not currently) used next node for that slot. Type: fix Signed-off-by: Christian Hopps <chopps@labn.net> Change-Id: I7ee607625da874e320158b80f12ddc16e377f8e9
2019-10-07vlib: move thread barrier around mod of global node next dataChristian E. Hopps1-6/+5
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>
2019-07-23vlib: address vlib_error_t scaling issueDave Barach1-1/+1
Encoding the vpp node index into the vlib_error_t as a 10-bit quantity limits us to 1K graph nodes. Unfortunately, a few nodes need 6 bit per-node error codes. Only a very few nodes have so many counters. It turns out that there are about 2K total error counters in the system, which is (approximately) the maximum error heap index. The current (index,code) encoding limits the number of interfaces to around 250, since each interface has two associated graph nodes and we have about 500 "normal, interior" graph node This patch adds an error-index to node-index map, so we can store error heap indices directly in the vlib_buffer_t. Type: refactor Change-Id: I28101cad3d8750819e27b8785fc0cf71ff54f79a Signed-off-by: Dave Barach <dave@barachs.net>
2019-05-29Break out the broom for some cleanup workDave Barach1-0/+28
Maintain the MAINTAINERS file. Removed src/plugins/*.am listings. Added a couple of plugins. Add vlib_process_create (vlib_main_t *vm, char *name, vlib_node_function_t *f, u32 log2_n_stack_bytes); /** @brief Create a vlib process * @param vm &vlib_global_main * @param f the process node function * @param log2_n_stack_bytes size of the process stack, defaults to 16K * @return newly-create node index * @warning call only on the main thread. Barrier sync required. */ This function makes it easy to spin up periodic processes when features are enabled for the first time. That coding pattern is highly recommended. Update the emacs-lisp plugin generator to use vlib_process_create, instead of generating static periodic process nodes. Change-Id: Icda33e93b9034779d3a3e228cd1110af14b058a5 Signed-off-by: Dave Barach <dave@barachs.net>
2019-03-26node: vector must be checked with vec_headerKingwel Xie1-1/+1
see register_node, node-name might be a vector Change-Id: I883ec51c1fa9aa4da4ba6cba415a39bb6a4331e1 Signed-off-by: Kingwel Xie <kingwel.xie@ericsson.com>
2019-03-10Perf tune get_frame_size_infoDave Barach1-0/+3
It turns out that for scalar sizes 0..24, frames are always the same size. That range includes all current use-cases - and then some - so get rid of the hash table. Old code preserved under #ifdef VLIB_SUPPORTS_ARBITRARY_SCALAR_SIZES. Change-Id: Ic005c7143c9639f77d1a0fadd2fc0e90dccb68c1 Signed-off-by: Dave Barach <dbarach@cisco.com>
2018-11-30Metadata / opaque formatting belongs in vppDave Barach1-0/+1
VPP graph dispatch trace record description: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Major Version | Minor Version | NStrings | ProtoHint | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer index (big endian) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + VPP graph node name ... ... | NULL octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Metadata ... ... | NULL octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Opaque ... ... | NULL octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Opaque 2 ... ... | NULL octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPP ASCII packet trace (if NStrings > 4) | NULL octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet data (up to 16K) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Graph dispatch records comprise a version stamp, an indication of how many NULL-terminated strings will follow the record header, and a protocol hint. The buffer index allows downstream consumers of these data to easily filter/track single packets as they traverse the forwarding graph. FWIW, the 32-bit buffer index is stored in big endian format. As of this writing, major version = 1, minor version = 0. Nstrings will be either 4 or 5. Here is the current set of protocol hints: typedef enum { VLIB_NODE_PROTO_HINT_NONE = 0, VLIB_NODE_PROTO_HINT_ETHERNET, VLIB_NODE_PROTO_HINT_IP4, VLIB_NODE_PROTO_HINT_IP6, VLIB_NODE_PROTO_HINT_TCP, VLIB_NODE_PROTO_HINT_UDP, VLIB_NODE_N_PROTO_HINTS, } vlib_node_proto_hint_t; Example: VLIB_NODE_PROTO_HINT_IP6 means that the first octet of packet data SHOULD be 0x60, and should begin an ipv6 packet header. Change-Id: Idf310bad80cc0e4207394c80f18db5f77c378741 Signed-off-by: Dave Barach <dave@barachs.net>
2018-11-13vlib rename vlib_frame_args(...) to vlib_frame_scalar_args(..)Damjan Marion1-1/+1
Typically we have scalar_size == 0, so it doesn't matter but vlib_frame_args was providing pointer to scalar frame data, not vector data. To avoid future confusion function is renamed to vlib_frame_scalar_args(...) Change-Id: I48b75523b46d487feea24f3f3cb10c528dde516f Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-10-23c11 safe string handling supportDave Barach1-3/+3
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-08-28vlib: add 'show node' and 'set node function' CLIDamjan Marion1-0/+1
Change-Id: I084d7c9e34329f10b5fe45e0b157c4defe0f2811 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-06-13Stat segment / client: show run" works nowDave Barach1-11/+19
Seems to have minimal-to-zero performance consequences. Data appears accurate: result match the debug CLI output. Checked at low rates, 27 MPPS sprayed across two worker threads. Change-Id: I09ede5150b88a91547feeee448a2854997613004 Signed-off-by: Dave Barach <dave@barachs.net>
2018-05-29Add VLIB_NODE_FN() macro to simplify multiversioning of node functionsDamjan Marion1-0/+20
Change-Id: Ibab5e27277f618ceb2d543b9d6a1a5f191e7d1db Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-01-09api: refactor vlibmemoryFlorin Coras1-0/+54
- separate client/server code for both memory and socket apis - separate memory api code from generic vlib api code - move unix_shared_memory_fifo to svm and rename to svm_fifo_t - overall declutter Change-Id: I90cdd98ff74d0787d58825b914b0f1eafcfa4dc2 Signed-off-by: Florin Coras <fcoras@cisco.com>
2017-07-13VPP-895 multi-thread: fix vpp crash on show runtimeIgor Mikhailov (imichail)1-0/+29
In multi-threaded model (e.g. 1 main and 1 worker threads), after an ethernet interface is deleted (e.g. vhost-user interface), 'show runtime' command produces garbled output and sometimes leads to vpp crash. The reason is because vlib_node_rename() frees and reallocates node's 'n->name' vector, however the change is not propagated into copies of the node on worker threads. Change-Id: Ibf22422913b7f2df22f70f3b2fe8dafd34c1dd06 Signed-off-by: Igor Mikhailov (imichail) <imichail@cisco.com> (cherry picked from commit 02989064e4c26a4940a5292ba6c47023e6dd3131)
2017-06-30VPP debug image with worker threads hit assert on adding IP route with ↵Neale Ranns1-0/+20
traffic (VPP-892) When stacking DPOs the VLIB graph is also updated to add the edge between the nodes, if this edge does not yet exist. This addition should be done with the workers stopped. Change-Id: I327e4d7d26f0b23eb280f17e4619ff2093ff7940 Signed-off-by: Neale Ranns <nranns@cisco.com> (cherry picked from commit c02bd03ddf5eec9e9c79811360685f13e4ba8ee1)
2017-06-09Implement sack based tcp loss recovery (RFC 6675)Florin Coras1-0/+1
- refactor existing congestion control code (RFC 6582/5681). Handling of ack feedback now consists of: ack parsing, cc event detection, event handling, congestion control update - extend sack scoreboard to support sack based retransmissions - basic implementation of Eifel detection algorithm (RFC 3522) for detecting spurious retransmissions - actually initialize the per-thread frame freelist hash tables - increase worker stack size to 2mb - fix session queue node out-of-buffer handling - ensure that the local buffer cache vec_len matches reality - avoid 2x spurious event requeues when short of buffers - count out-of-buffer events - make the builtin server thread-safe - fix bihash template threading issue: need to paint -1 across uninitialized working_copy_length vector elements (via rebase from master) Change-Id: I646cb9f1add9a67d08f4a87badbcb117980ebfc4 Signed-off-by: Florin Coras <fcoras@cisco.com> Signed-off-by: Dave Barach <dbarach@cisco.com>
2017-04-06Use thread local storage for thread indexDamjan Marion1-1/+1
This patch deprecates stack-based thread identification, Also removes requirement that thread stacks are adjacent. Finally, possibly annoying for some folks, it renames all occurences of cpu_index and cpu_number with thread index. Using word "cpu" is misleading here as thread can be migrated ti different CPU, and also it is not related to linux cpu index. Change-Id: I68cdaf661e701d2336fc953dcb9978d10a70f7c1 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-03-16vlib: make runtime_data thread-localDamjan Marion1-3/+1
Change-Id: I4aa3e7e42fb81211de1aed07dc7befee87a1e18b Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+631
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>