[V4] app/testpmd: fix GENEVE parsing in csum forward mode

Message ID 20220221132423.14343-1-rzidane@nvidia.com (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers
Series [V4] app/testpmd: fix GENEVE parsing in csum forward mode |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/github-robot: build success github build: passed
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-aarch64-unit-testing success Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-x86_64-compile-testing success Testing PASS
ci/iol-aarch64-compile-testing success Testing PASS
ci/iol-x86_64-unit-testing success Testing PASS
ci/iol-abi-testing success Testing PASS

Commit Message

Raja Zidane Feb. 21, 2022, 1:24 p.m. UTC
  The csum FWD mode parses any received packet to set mbuf offloads for the
transmitting burst, mainly in the checksum/TSO areas.
In the case of a tunnel header, the csum FWD tries to detect known tunnels
by the standard definition using the header'sdata and fallback to check the
packet type in the mbuf to see if the Rx port driver already sign the
packet as a tunnel.
In the fallback case, the csum assumes the tunnel is VXLAN and parses the
tunnel as VXLAN.
When the GENEVE tunnel was added to the known tunnels in csum, its parsing
trial was wrongly located after the pkt type detection, causing the csum to
parse the GENEVE header as VXLAN when the Rx port set the tunnel packet
type.

Remove the fall back case to VxLan.
Log error of unrecognized tunnel if no tunnel was parsed successfully.

Fixes: c10a026c3b03 ("app/testpmd: introduce vxlan parsing function in csum fwd engine")
Cc: stable@dpdk.org

Signed-off-by: Raja Zidane <rzidane@nvidia.com>
---
V2: Log error when an unrecognized tunnel is found (unknown UDP dst port), instead of parsing it as VxLan by default.
V3: revert unneeded changes (swapping parse_geneve & parse_vxlan).
V4: Log unknown tunnel error in debug mode.
 app/test-pmd/csumonly.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)
  

Comments

Ferruh Yigit Feb. 21, 2022, 5:36 p.m. UTC | #1
On 2/21/2022 1:24 PM, Raja Zidane wrote:
> The csum FWD mode parses any received packet to set mbuf offloads for the
> transmitting burst, mainly in the checksum/TSO areas.
> In the case of a tunnel header, the csum FWD tries to detect known tunnels
> by the standard definition using the header'sdata and fallback to check the
> packet type in the mbuf to see if the Rx port driver already sign the
> packet as a tunnel.
> In the fallback case, the csum assumes the tunnel is VXLAN and parses the
> tunnel as VXLAN.
> When the GENEVE tunnel was added to the known tunnels in csum, its parsing
> trial was wrongly located after the pkt type detection, causing the csum to
> parse the GENEVE header as VXLAN when the Rx port set the tunnel packet
> type.
> 
> Remove the fall back case to VxLan.
> Log error of unrecognized tunnel if no tunnel was parsed successfully.
> 
> Fixes: c10a026c3b03 ("app/testpmd: introduce vxlan parsing function in csum fwd engine")
> Cc:stable@dpdk.org
> 
> Signed-off-by: Raja Zidane<rzidane@nvidia.com>

Moving Aman's ack from previous version:
Acked-by: Aman Singh <aman.deep.singh@intel.com>

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied to dpdk-next-net/main, thanks.
  

Patch

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 02bc3929c7..5274d498ee 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -258,8 +258,7 @@  parse_gtp(struct rte_udp_hdr *udp_hdr,
 /* Parse a vxlan header */
 static void
 parse_vxlan(struct rte_udp_hdr *udp_hdr,
-	    struct testpmd_offload_info *info,
-	    uint32_t pkt_type)
+	    struct testpmd_offload_info *info)
 {
 	struct rte_ether_hdr *eth_hdr;
 
@@ -267,8 +266,7 @@  parse_vxlan(struct rte_udp_hdr *udp_hdr,
 	 * default vxlan port (rfc7348) or that the rx offload flag is set
 	 * (i40e only currently)
 	 */
-	if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT) &&
-		RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
+	if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT))
 		return;
 
 	update_tunnel_outer(info);
@@ -922,8 +920,7 @@  pkt_burst_checksum_forward(struct fwd_stream *fs)
 						RTE_MBUF_F_TX_TUNNEL_VXLAN_GPE;
 					goto tunnel_update;
 				}
-				parse_vxlan(udp_hdr, &info,
-					    m->packet_type);
+				parse_vxlan(udp_hdr, &info);
 				if (info.is_tunnel) {
 					tx_ol_flags |=
 						RTE_MBUF_F_TX_TUNNEL_VXLAN;
@@ -935,6 +932,12 @@  pkt_burst_checksum_forward(struct fwd_stream *fs)
 						RTE_MBUF_F_TX_TUNNEL_GENEVE;
 					goto tunnel_update;
 				}
+				/* Always keep last. */
+				if (unlikely(RTE_ETH_IS_TUNNEL_PKT(
+							m->packet_type) != 0)) {
+					TESTPMD_LOG(DEBUG, "Unknown tunnel packet. UDP dst port: %hu",
+						udp_hdr->dst_port);
+				}
 			} else if (info.l4_proto == IPPROTO_GRE) {
 				struct simple_gre_hdr *gre_hdr;