summaryrefslogtreecommitdiffstats
path: root/src/vpp-api/client/client.c
diff options
context:
space:
mode:
authorAndrew Yourtchenko <ayourtch@gmail.com>2018-10-05 20:36:03 +0200
committerJohn Lo <loj@cisco.com>2018-10-09 01:24:43 +0000
commit20e6d36bca61dc004131d9be5385c71f8553e1fc (patch)
treeaa04e55b8f97ebe342ef838fc3143025be76c350 /src/vpp-api/client/client.c
parent4a0559a804237f71b19d395b0fd25029cd03b248 (diff)
vnet: ethernet-input incorrectly sets l3_hdr_offset in some cases
The issue surfaced when developing the tap GSO code, with an iteration where output path is reliant on vnet_buffer (b0)->l3_hdr_offset being set correctly in the input path, during performance testing. Adding a workaround in the TX path shows that the issue surfaces only for relatively few packets during the test (about 100 out of 600000). Analysis shows the issue arises if the ethernet-input is handling two untagged packets with different sw_if_index values - then the accelerated path punts to slow path, before the setting of the l2.l2_len values is done, thus resulting in them being 0, and l3_hdr_offset being the same as l2_hdr_offset, wreaking havoc on TX path. The solution is to move the l2_hdr_offset calculation into a place where it is done for all the packets, and move the l3_hdr_offset calculation into the determine_next_node() function - as that function is also the one setting the special-case l2.l2_len value for tagged packets and moving the current_data for the L2 case. Change-Id: If728c7715e011930c1887691188c98055bddde67 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Diffstat (limited to 'src/vpp-api/client/client.c')
0 files changed, 0 insertions, 0 deletions