All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Singh, Aman Deep" <aman.deep.singh@intel.com>
To: Raja Zidane <rzidane@nvidia.com>, <dev@dpdk.org>
Cc: Matan Azrad <matan@nvidia.com>, <stable@dpdk.org>
Subject: Re: [PATCH V2] app/testpmd: fix GENEVE parsing in csum forward mode
Date: Fri, 18 Feb 2022 14:39:57 +0530	[thread overview]
Message-ID: <667368b7-5897-63ef-6512-d2097d626afd@intel.com> (raw)
In-Reply-To: <20220216123732.32617-1-rzidane@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 3300 bytes --]


On 2/16/2022 6:07 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: ea0e711b8ae0 ("app/testpmd: add GENEVE parsing")
> 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.
>
>   app/test-pmd/csumonly.c | 23 +++++++++++++----------
>   1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index 02bc3929c7..210f4263f8 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -255,11 +255,10 @@ parse_gtp(struct rte_udp_hdr *udp_hdr,
>   	info->l2_len += RTE_ETHER_GTP_HLEN;
>   }
>   
> -/* Parse a vxlan header */
> +/* 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,19 +920,24 @@ 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_geneve(udp_hdr, &info);
>   				if (info.is_tunnel) {
>   					tx_ol_flags |=
> -						RTE_MBUF_F_TX_TUNNEL_VXLAN;
> +						RTE_MBUF_F_TX_TUNNEL_GENEVE;
>   					goto tunnel_update;
>   				}
> -				parse_geneve(udp_hdr, &info);
> +				parse_vxlan(udp_hdr, &info);
>   				if (info.is_tunnel) {
>   					tx_ol_flags |=
> -						RTE_MBUF_F_TX_TUNNEL_GENEVE;
> +						RTE_MBUF_F_TX_TUNNEL_VXLAN;

After adding default case, i suppose swapping of parse_vxlan & parse_geneve is not needed.
Can we revert these above changes.

>   					goto tunnel_update;
>   				}
> +				/* Always keep last. */
> +				if (unlikely(RTE_ETH_IS_TUNNEL_PKT(
> +							m->packet_type) != 0)) {
> +					TESTPMD_LOG(ERR, "Unknown tunnel packet. UDP dst port: %hu",
> +						udp_hdr->dst_port);
> +				}
>   			} else if (info.l4_proto == IPPROTO_GRE) {
>   				struct simple_gre_hdr *gre_hdr;
>   

[-- Attachment #2: Type: text/html, Size: 3826 bytes --]

  reply	other threads:[~2022-02-18  9:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-05  3:44 [PATCH] app/testpmd: fix GENEVE parsing in csum forward mode Raja Zidane
2022-01-18  9:51 ` Ferruh Yigit
2022-01-18 11:27   ` Matan Azrad
2022-01-18 12:28     ` Ferruh Yigit
2022-01-18 12:55       ` Matan Azrad
2022-01-18 13:03         ` Ferruh Yigit
2022-01-18 13:19           ` Matan Azrad
2022-01-20 10:46             ` Singh, Aman Deep
2022-01-30 11:18               ` Raja Zidane
2022-01-31 16:47                 ` Singh, Aman Deep
2022-02-15 14:31                   ` Raja Zidane
2022-02-15 14:43                     ` Singh, Aman Deep
2022-02-16  2:02                     ` Xing, Beilei
2022-02-16 12:37 ` [PATCH V2] " Raja Zidane
2022-02-18  9:09   ` Singh, Aman Deep [this message]
2022-02-20 12:09   ` [PATCH V3] " Raja Zidane
2022-02-21 10:24     ` Singh, Aman Deep
2022-02-21 12:08     ` Ferruh Yigit
2022-02-21 13:24     ` [PATCH V4] " Raja Zidane
2022-02-21 17:36       ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=667368b7-5897-63ef-6512-d2097d626afd@intel.com \
    --to=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=matan@nvidia.com \
    --cc=rzidane@nvidia.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.