Hi all, I'm currently porting a plugin from v18.01 to v19.08 and having an issue with VPP pcap functionality in the newer version. The plugin has added the following node (ip4-mac-output) to the ip4-output feature arc and when it's enabled I see duplicate packets when taking a tx pcap via vppctl (so two identical SYNs, SYN/ACKs, etc.):
VNET_FEATURE_INIT (ip4_mac_output, static) =
{
.arc_name = "ip4-output",
.node_name = "ip4-mac-output",
.runs_before = 0,
};
VLIB_REGISTER_NODE (ip4_mac_output_node) =
{
.function = ip4_mac_output,
.name = "ip4-mac-output",
.vector_size = sizeof (u32),
.type = VLIB_NODE_TYPE_INTERNAL,
.n_errors = ARRAY_LEN(mac_error_strings),
.error_strings = mac_error_strings,
.n_next_nodes = MAC_OUTPUT_N_NEXT,
.next_nodes = {
[MAC_OUTPUT_NEXT_INTERFACE_OUTPUT] = "interface-output",
[MAC_OUTPUT_NEXT_DROP] = "error-drop",
},
};
The node receives a packet and always directs it to 'interface-output' unless
in error case. I have tested this with all business logic removed from the
node, so the issue doesn't appear related to what the node does, rather the
position of the node in the packet processing graph. When I disable this node,
the tx pcaps do not show the duplicate packets.
I added some breakpoints to see when the interface-node was getting called and
packets getting added to pcap file. With the plugin node (ip4-mac-output)
disabled I see *vnet_interface_pcap_tx_trace* called once, but with
ip4-mac-output enabled I see it called twice.
*TRACE 1*
Breakpoint 2, vnet_interface_pcap_tx_trace (sw_if_index_from_buffer=1,
frame=<optimized out>, node=<optimized out>, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
844 pcap_add_buffer_to_mul_file
(&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_main, vm, bi0,
vlib_global_main.pktfilter.snaplen,
&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_enable);
(gdb) bt
#0 *vnet_interface_pcap_tx_trace* (sw_if_index_from_buffer=1, frame=<optimized
out>, node=<optimized out>, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
#1 vnet_per_buffer_interface_output_node_fn_avx2 (vm=0x2b5b3994c580,
node=<optimized out>, frame=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:940
#2 0x00002b5b31858eeb in dispatch_node (last_time_stamp=<optimized out>,
frame=0x2b5bbccd9680, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x2b5bbcbf2180, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vlib/main.c:1302
#3 dispatch_pending_node (vm=vm@entry=0x2b5b3994c580,
pending_frame_index=pending_frame_index@entry=4, last_time_stamp=<optimized
out>)
*TRACE 2*
Breakpoint 2, vnet_interface_pcap_tx_trace (sw_if_index_from_buffer=0,
frame=<optimized out>, node=<optimized out>, vm=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
844 pcap_add_buffer_to_mul_file
(&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_main, vm, bi0,
vlib_global_main.pktfilter.snaplen,
&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_enable);
(gdb) bt
#0 *vnet_interface_pcap_tx_trace* (sw_if_index_from_buffer=0, frame=<optimized
out>, node=<optimized out>, vm=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
#1 vnet_interface_output_node (vm=<optimized out>, node=<optimized out>,
frame=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:918
#2 0x00002b5b31858eeb in dispatch_node (last_time_stamp=<optimized out>,
frame=0x2b5bbcbda340, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x2b5bbcbf2800, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vlib/main.c:1302
#3 dispatch_pending_node (vm=vm@entry=0x2b5b3994c580,
pending_frame_index=pending_frame_index@entry=5, last_time_stamp=<optimized
out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vlib/main.c:1481
When ip4-mac-output is disabled, I don't see TRACE 1 , I only see TRACE 2. When
ip4-mac-output is enabled, both of these stacks are invoked so packets get
added to the pcap file twice.
I have attached an https pcap with (enabled.pcap) and without (disabled.pcap)
ip4-mac-output node so you can see the duplicate packets.
Can anyone suggest why I might be seeing this extra call (and thus duplicate
behaviour in pcap) when the ip4-mac-output node is added to the ip4-output
feature arc? We did not see this behaviour in VPP 18.01.
Any thoughts welcome.
Many thanks,
Gerard
disabled.pcap
Description: Binary data
enabled.pcap
Description: Binary data
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16984): https://lists.fd.io/g/vpp-dev/message/16984 Mute This Topic: https://lists.fd.io/mt/75543730/21656 Mute #vpp: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp Mute #vnet: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vnet Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
