summaryrefslogtreecommitdiffstats
path: root/src/vnet/fib
diff options
context:
space:
mode:
authorChristian E. Hopps <chopps@chopps.org>2019-09-28 21:36:36 -0400
committerDave Barach <openvpp@barachs.net>2019-10-07 14:02:37 +0000
commitd3122ef4ecfa9a515cc39c1632d29e43fa771b2a (patch)
tree12b0f5c75365d931523b6d4ee783ff3b14e40814 /src/vnet/fib
parent1dc90824ff2ff38af2274d674f3922e3a2e60811 (diff)
vlib: move thread barrier around mod of global node next data
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>
Diffstat (limited to 'src/vnet/fib')
0 files changed, 0 insertions, 0 deletions