summaryrefslogtreecommitdiffstats
path: root/test/scapy_handlers
diff options
context:
space:
mode:
authorSteven <sluong@cisco.com>2017-09-26 15:58:24 -0700
committerFlorin Coras <florin.coras@gmail.com>2017-09-28 02:40:49 +0000
commit3fd57e67532bd55701bef7365adc17da229a44dc (patch)
tree265f1588284394b0cd60c60447435e134c485138 /test/scapy_handlers
parentd84f2ef54a457918f21bb0ee82392274b62611fe (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> (cherry picked from commit 4ff586d1c6fc5c40e1548cd6f221a8a7f3ad033b)
Diffstat (limited to 'test/scapy_handlers')
0 files changed, 0 insertions, 0 deletions