DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Huisong Li <lihuisong@huawei.com>, dev@dpdk.org
Cc: thomas@monjalon.net, aman.deep.singh@intel.com,
	yuying.zhang@intel.com, zhichaox.zeng@intel.com
Subject: Re: [PATCH v2] app/testpmd: fix UDP cksum error for UFO enable
Date: Fri, 3 Nov 2023 01:31:36 +0000	[thread overview]
Message-ID: <62dbcb50-31b0-41a2-9d83-a53b01abd0a6@amd.com> (raw)
In-Reply-To: <20230802025520.8000-1-lihuisong@huawei.com>

On 8/2/2023 3:55 AM, Huisong Li wrote:
> The command "tso set <tso_segsz> <port_id>" is used to enable UFO, please
> see commit ce8e6e742807 ("app/testpmd: support UFO in checksum engine")
> 
> The above patch configures the RTE_MBUF_F_TX_UDP_SEG to enable UFO only if
> tso_segsz is set. 
>

"The above patch sets the RTE_MBUF_F_TX_UDP_SEG in mbuf ol_flags, only
by checking if 'tso_segsz' is set, but missing check if UFO offload
(RTE_ETH_TX_OFFLOAD_UDP_TSO) supported by device."


> Then tx_prepare() may call rte_net_intel_cksum_prepare()
> to compute pseudo header checksum (because some PMDs may supports TSO).
>

Not sure what do you mean by '(because some PMDs may supports TSO)'?

Do you mean something like following:
"RTE_MBUF_F_TX_UDP_SEG flag causes driver that supports TSO/UFO to
compute pseudo header checksum."


> As a result, if the peer sends UDP packets, all packets with UDP checksum
> error are received for the PMDs only supported TSO.
> 

"As a result, if device only supports TSO, but not UFO, UDP packet
checksum will be wrong."


> So enabling UFO also depends on if driver has RTE_ETH_TX_OFFLOAD_UDP_TSO
> capability. Similarly, TSO also need to do like this.
> 
> In addition, this patch also fixes cmd_tso_set_parsed() for UFO to make
> it better to support TSO and UFO.
> 
> Fixes: ce8e6e742807 ("app/testpmd: support UFO in checksum engine")
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> ---
>  v2: add handle for tunnel TSO offload in process_inner_cksums
> 
> ---
>  app/test-pmd/cmdline.c  | 47 +++++++++++++++++++++--------------------
>  app/test-pmd/csumonly.c | 11 ++++++++--
>  2 files changed, 33 insertions(+), 25 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 0d0723f659..8be593d405 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -4906,6 +4906,7 @@ cmd_tso_set_parsed(void *parsed_result,
>  {
>  	struct cmd_tso_set_result *res = parsed_result;
>  	struct rte_eth_dev_info dev_info;
> +	uint64_t offloads;
>  	int ret;
>  
>  	if (port_id_is_invalid(res->port_id, ENABLED_WARN))
> @@ -4922,37 +4923,37 @@ cmd_tso_set_parsed(void *parsed_result,
>  	if (ret != 0)
>  		return;
>  
> -	if ((ports[res->port_id].tso_segsz != 0) &&
> -		(dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_TCP_TSO) == 0) {
> -		fprintf(stderr, "Error: TSO is not supported by port %d\n",
> -			res->port_id);
> -		return;
> +	if (ports[res->port_id].tso_segsz != 0) {
> +		if ((dev_info.tx_offload_capa & (RTE_ETH_TX_OFFLOAD_TCP_TSO |
> +					RTE_ETH_TX_OFFLOAD_UDP_TSO)) == 0) {
> +			fprintf(stderr, "Error: both TSO and UFO are not supported by port %d\n",
> +				res->port_id);
> +			return;
> +		}
> +		/* display warnings if configuration is not supported by the NIC */
> +		if ((dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_TCP_TSO) == 0)
> +			fprintf(stderr, "Warning: port %d doesn't support TSO\n",
> +				res->port_id);
> +		if ((dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_UDP_TSO) == 0)
> +			fprintf(stderr, "Warning: port %d doesn't support UFO\n",
> +				res->port_id);
>

Requesting TSO/UFO by setting 'tso_segsz', but device capability missing
is an error case, so OK to have first message.

But only supporting TSO or UFO is not an error case, not sure about
logging this. But even it is logged, I think it shouldn't be to stderr
or it should say "Warning: ", a regular logging can be done.


>  	}
>  
>  	if (ports[res->port_id].tso_segsz == 0) {
>  		ports[res->port_id].dev_conf.txmode.offloads &=
> -						~RTE_ETH_TX_OFFLOAD_TCP_TSO;
> -		printf("TSO for non-tunneled packets is disabled\n");
> +			~(RTE_ETH_TX_OFFLOAD_TCP_TSO | RTE_ETH_TX_OFFLOAD_UDP_TSO);
> +		printf("TSO and UFO for non-tunneled packets is disabled\n");
>  	} else {
> -		ports[res->port_id].dev_conf.txmode.offloads |=
> -						RTE_ETH_TX_OFFLOAD_TCP_TSO;
> -		printf("TSO segment size for non-tunneled packets is %d\n",
> +		offloads = (dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_TCP_TSO) ?
> +					RTE_ETH_TX_OFFLOAD_TCP_TSO : 0;
> +		offloads |= (dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_UDP_TSO) ?
> +					RTE_ETH_TX_OFFLOAD_UDP_TSO : 0;
> +		ports[res->port_id].dev_conf.txmode.offloads |= offloads;
> +		printf("segment size for non-tunneled packets is %d\n",
>  			ports[res->port_id].tso_segsz);
>  	}
> -	cmd_config_queue_tx_offloads(&ports[res->port_id]);
> -
> -	/* display warnings if configuration is not supported by the NIC */
> -	ret = eth_dev_info_get_print_err(res->port_id, &dev_info);
> -	if (ret != 0)
> -		return;
> -
> -	if ((ports[res->port_id].tso_segsz != 0) &&
> -		(dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_TCP_TSO) == 0) {
> -		fprintf(stderr,
> -			"Warning: TSO enabled but not supported by port %d\n",
> -			res->port_id);
> -	}
>  

Above is redundant check, and introduced with commit [1], I assume by
mistake. Since removing above check is not related to UFO, what do you
think to separate it to its own patch?

[1]
Fixes: 3926dd2b6668 ("app/testpmd: enforce offload capabilities check")


> +	cmd_config_queue_tx_offloads(&ports[res->port_id]);
>  	cmd_reconfig_device_queue(res->port_id, 1, 1);
>  }
>  
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index c103e54111..21210aff43 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -466,6 +466,12 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
>  	uint64_t ol_flags = 0;
>  	uint32_t max_pkt_len, tso_segsz = 0;
>  	uint16_t l4_off;
> +	uint64_t all_tunnel_tso = RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO |
> +				RTE_ETH_TX_OFFLOAD_GRE_TNL_TSO |
> +				RTE_ETH_TX_OFFLOAD_IPIP_TNL_TSO |
> +				RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO |
> +				RTE_ETH_TX_OFFLOAD_IP_TNL_TSO |
> +				RTE_ETH_TX_OFFLOAD_UDP_TNL_TSO;
>  
>  	/* ensure packet is large enough to require tso */
>  	if (!info->is_tunnel) {
> @@ -505,7 +511,7 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
>  		udp_hdr = (struct rte_udp_hdr *)((char *)l3_hdr + info->l3_len);
>  		/* do not recalculate udp cksum if it was 0 */
>  		if (udp_hdr->dgram_cksum != 0) {
> -			if (tso_segsz)
> +			if (tso_segsz && (tx_offloads & RTE_ETH_TX_OFFLOAD_UDP_TSO))
>  				ol_flags |= RTE_MBUF_F_TX_UDP_SEG;
>  			else if (tx_offloads & RTE_ETH_TX_OFFLOAD_UDP_CKSUM) {
>  				ol_flags |= RTE_MBUF_F_TX_UDP_CKSUM;
> @@ -528,7 +534,8 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
>  #endif
>  	} else if (info->l4_proto == IPPROTO_TCP) {
>  		tcp_hdr = (struct rte_tcp_hdr *)((char *)l3_hdr + info->l3_len);
> -		if (tso_segsz)
> +		if (tso_segsz &&
> +		    (tx_offloads & (RTE_ETH_TX_OFFLOAD_TCP_TSO | all_tunnel_tso)))
>

Should we check 'all_tunnel_tso', and why they are checked only for TCP?

As far as I can see some tunnel TSO offloads should case setting
relevant mbuf flags, like RTE_MBUF_F_TX_TUNNEL_UDP or
RTE_ETH_TX_OFFLOAD_IP_TNL_TSO.

With above check, if RTE_ETH_TX_OFFLOAD_TCP_TSO  not set but only
RTE_ETH_TX_OFFLOAD_UDP_TNL_TSO set, we still set 'RTE_MBUF_F_TX_TCP_SEG'
flag but not 'RTE_MBUF_F_TX_TUNNEL_UDP' flag.

I assume intention is to be close to previous implementation, where only
tso_segsz checked, and cover as much as possible TSO offload requests,
but not sure if this is accurate with expected usage.

>  			ol_flags |= RTE_MBUF_F_TX_TCP_SEG;
>  		else if (tx_offloads & RTE_ETH_TX_OFFLOAD_TCP_CKSUM) {
>  			ol_flags |= RTE_MBUF_F_TX_TCP_CKSUM;


  parent reply	other threads:[~2023-11-03  1:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28  2:13 [PATCH] " Huisong Li
2023-08-02  2:55 ` [PATCH v2] " Huisong Li
2023-10-20  3:38   ` lihuisong (C)
2023-10-27  6:15   ` fengchengwen
2023-11-03  1:31   ` Ferruh Yigit [this message]
2023-11-03  9:09     ` lihuisong (C)
2023-11-03 10:42       ` Ferruh Yigit
2023-11-06  4:13         ` lihuisong (C)
2023-11-06 10:09           ` Ferruh Yigit
2023-11-06 12:29             ` lihuisong (C)
2023-11-07  4:11 ` [PATCH v3 0/2] " Huisong Li
2023-11-07  4:11   ` [PATCH v3 1/2] app/testpmd: remove useless code for TSO setting command Huisong Li
2023-11-07  4:11   ` [PATCH v3 2/2] app/testpmd: fix UDP cksum error for UFO enable Huisong Li
2023-11-07  9:54   ` [PATCH v3 0/2] " 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=62dbcb50-31b0-41a2-9d83-a53b01abd0a6@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=lihuisong@huawei.com \
    --cc=thomas@monjalon.net \
    --cc=yuying.zhang@intel.com \
    --cc=zhichaox.zeng@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).