summaryrefslogtreecommitdiffstats
path: root/extras/libmemif/examples/examples_doc.md
diff options
context:
space:
mode:
authorSteven <sluong@cisco.com>2017-09-26 15:58:24 -0700
committerDamjan Marion <dmarion.lists@gmail.com>2017-09-28 00:09:15 +0000
commit4ff586d1c6fc5c40e1548cd6f221a8a7f3ad033b (patch)
treebd2d739d9c4998b1581bae1a7be408b4bfba6ef4 /extras/libmemif/examples/examples_doc.md
parent75a17ecddc9dc579a3aecfc5b53cbb60e993965f (diff)
tun/tap: Bad packets sent to kernel via tun/tap interface
It was observed that under heavy traffic, VPP accidentally sent traffic with the wrong source and destination to the tun/tap interface. Traffic appears to be sent to the wrong direction. This problem is only seen when worker thread is configured. When worker thread is used, TX and RX may reside in different core. Yet both TX and RX threads are sharing the same global variable, namely iovecs without any mutex or memory barrier protection. This creates a race condition when heavy traffic is blasted to VPP, like 1000 pps. We could create a mutex or memory barrier to ensure atomic memory access. But why bother? It is a lot cheaper to just decouple the iovecs such that TX and RX have their own iovecs. Change-Id: I86a5a19bd8de54d54f32e1f0845bae6a81bbf686 Signed-off-by: Steven <sluong@cisco.com>
Diffstat (limited to 'extras/libmemif/examples/examples_doc.md')
0 files changed, 0 insertions, 0 deletions