You’ve shown that your proprietary code runs a packet through a path which hits
the tx pcap recorder twice, so you get two trace records.
Solutions include creating a no-pcap-trace variant node, or marking buffer
metadata to suppress the second record.
HTH... Dave
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of
gerard.ke...@owmobility.com
Sent: Thursday, July 16, 2020 11:17 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] v19.08 - duplicate packets in pcap after adding node to
ip4-output feature arc - #vpp #vnet
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16986): https://lists.fd.io/g/vpp-dev/message/16986
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]
-=-=-=-=-=-=-=-=-=-=-=-
