From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4221A42502; Tue, 5 Sep 2023 10:50:02 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 343BE40289; Tue, 5 Sep 2023 10:50:02 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 118644026A for ; Tue, 5 Sep 2023 10:50:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693903800; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xov3rW3ZawzuDHfkPl6yuplaLvBwKguuFnU/lBloec4=; b=gSzMZm9iD0UJkJ7Ypf51N1YawBIIDXeoZsLOhMkIfb+7pywENi+Lp7BUyErrLz5An7xc4B xby9rsBoFs/NTsEj+9VXD5RcD6hfQpMn7dwt9+4BXuGER28UGG6kOGq0mgLtDBOiCYaBi9 mG8qkhYFnO+7h53542SLFnPuZYjCeV4= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-117-2xiTS4YhOsSa2vUCBBZwWg-1; Tue, 05 Sep 2023 04:49:57 -0400 X-MC-Unique: 2xiTS4YhOsSa2vUCBBZwWg-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-31f3233861aso1269354f8f.2 for ; Tue, 05 Sep 2023 01:49:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693903796; x=1694508596; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xov3rW3ZawzuDHfkPl6yuplaLvBwKguuFnU/lBloec4=; b=K7SikBC6U5kVV8WPXBcYt4X6+TeLW13UHwalqT+vrZhutel+L/yJ9y+W50jpvLN5ob 4EpXIEFqedocf44FV6p/ZKJlb1SKlxhAjlOZZQziw3tQl2Jc4j/ydHd4MES1DY0E5ctQ BkwLnVIi4v2UG74vo3e+kE1ICLM6fWeP22NvNWpoSUj/6hh1E6F3r14YSaj28reCg/cF SSt4h3C42uRGR2OU7urP6wz5n/ftgmEGxyYZAQ6Kf1zYGvbzztiLs6ng2KcT215vuox7 l+QFT3Xyc9eJadwgVM9rI5jwWeMrmVIHN26usqvjX0C81M+hx4UW3wwMrcZ2xBNHK4V5 ST0g== X-Gm-Message-State: AOJu0Yxk0Zjyrbo6PTtiLYTWs11jo9kgSyNP3hSYIoeQ+84Ndyl9zBLF PwDEudcA7TjEISJ58rR+JD4hCMR+hpEvK8JxQzoii4KM/1G5vf1uwQJ9kXRSQITrql2g1yYukc0 jXAw= X-Received: by 2002:a5d:4ccf:0:b0:315:a74c:f627 with SMTP id c15-20020a5d4ccf000000b00315a74cf627mr9070261wrt.16.1693903796387; Tue, 05 Sep 2023 01:49:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH5Im4TTijU5GxGs7xoj9x5QgT07tPr/klmgqqDBDyRdnonHFFUcntoPZQyuhe626iHOLtIsg== X-Received: by 2002:a5d:4ccf:0:b0:315:a74c:f627 with SMTP id c15-20020a5d4ccf000000b00315a74cf627mr9070247wrt.16.1693903796053; Tue, 05 Sep 2023 01:49:56 -0700 (PDT) Received: from [192.168.0.36] ([78.19.106.24]) by smtp.gmail.com with ESMTPSA id t2-20020a05600001c200b003196e992567sm16843717wrx.115.2023.09.05.01.49.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 01:49:55 -0700 (PDT) Message-ID: <023948d4-ff86-9f4f-baf0-1469b154c489@redhat.com> Date: Tue, 5 Sep 2023 09:49:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: "Zeng, ZhichaoX" , "Xu, HailinX" , Xueming Li , "stable@dpdk.org" , "Wu, Jingjing" , "Xing, Beilei" , "Xu, Ke1" , "Zhang, Qi Z" Cc: "xuemingl@nvdia.com" , "dev@dpdk.org" , "Stokes, Ian" , "Mcnamara, John" , Luca Boccassi , "Xu, Qian Q" , Thomas Monjalon , "Peng, Yuan" , "Chen, Zhaoyan" , "Yang, Qiming" , "Zhou, YidingX" , "Cui, KaixinX" References: <20230817061332.16248-1-xuemingl@nvidia.com> <307bf0a5-b0a6-b602-64b8-8eff3dcf3905@redhat.com> From: Kevin Traynor Subject: Re: 22.11.3 patches review and test In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 05/09/2023 02:51, Zeng, ZhichaoX wrote: > > > Regards > Zhichao >> -----Original Message----- >> From: Kevin Traynor >> Sent: Monday, September 4, 2023 10:15 PM >> To: Zeng, ZhichaoX ; Xu, HailinX >> ; Xueming Li ; >> stable@dpdk.org; Wu, Jingjing ; Xing, Beilei >> ; Xu, Ke1 ; Zhang, Qi Z >> >> Cc: xuemingl@nvdia.com; dev@dpdk.org; Stokes, Ian ; >> Mcnamara, John ; Luca Boccassi >> ; Xu, Qian Q ; Thomas Monjalon >> ; Peng, Yuan ; Chen, >> Zhaoyan >> Subject: Re: 22.11.3 patches review and test >> >> On 04/09/2023 10:32, Kevin Traynor wrote: >>> On 01/09/2023 04:23, Zeng, ZhichaoX wrote: >>>>> -----Original Message----- >>>>> From: Kevin Traynor >>>>> Sent: Thursday, August 31, 2023 8:18 PM >>>>> To: Xu, HailinX ; Xueming Li >>>>> ; stable@dpdk.org; Wu, Jingjing >>>>> ; Xing, Beilei ; Xu, >>>>> Ke1 ; Zeng, ZhichaoX ; >>>>> Zhang, Qi Z >>>>> Cc: xuemingl@nvdia.com; dev@dpdk.org; Stokes, Ian >>>>> ; Mcnamara, John ; >>>>> Luca Boccassi ; Xu, Qian Q ; >>>>> Thomas Monjalon ; Peng, Yuan >>>>> ; Chen, Zhaoyan >>>>> Subject: Re: 22.11.3 patches review and test >>>>> >>>>> On 30/08/2023 17:25, Kevin Traynor wrote: >>>>>> On 29/08/2023 09:22, Xu, HailinX wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: Xueming Li >>>>>>>> Sent: Thursday, August 17, 2023 2:14 PM >>>>>>>> To: stable@dpdk.org >>>>>>>> Cc: xuemingl@nvdia.com; dev@dpdk.org; Abhishek Marathe >>>>>>>> ; Ali Alnubani >>>>>>>> ; Walker, Benjamin >>>>>>>> ; David Christensen >>>>>>>> ; Hemant Agrawal >>>>> ; >>>>>>>> Stokes, Ian ; Jerin Jacob >>>>>>>> ; Mcnamara, John >> ; >>>>>>>> Ju-Hyoung Lee ; Kevin Traynor >>>>>>>> ; Luca Boccassi ; Pei >>>>>>>> Zhang ; Xu, Qian Q ; >>>>>>>> Raslan Darawsheh ; Thomas Monjalon >>>>>>>> ; Yanghang Liu ; >> Peng, >>>>>>>> Yuan ; Chen, Zhaoyan >>>>> >>>>>>>> Subject: 22.11.3 patches review and test >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Here is a list of patches targeted for stable release 22.11.3. >>>>>>>> >>>>>>>> The planned date for the final release is 31th August. >>>>>>>> >>>>>>>> Please help with testing and validation of your use cases and >>>>>>>> report any issues/results with reply-all to this mail. For the >>>>>>>> final release the fixes and reported validations will be added to >>>>>>>> the release >>>>> notes. >>>>>>>> >>>>>>>> A release candidate tarball can be found at: >>>>>>>> >>>>>>>> https://dpdk.org/browse/dpdk-stable/tag/?id=v22.11.3-rc1 >>>>>>>> >>>>>>>> These patches are located at branch 22.11 of dpdk-stable repo: >>>>>>>> https://dpdk.org/browse/dpdk-stable/ >>>>>>>> >>>>>>>> Thanks. >>>>>>> >>>>>>> We are conducting DPDK testing and have found two issues. >>>>>>> >>>>>>> 1. The startup speed of testpmd is significantly slower in the os of SUSE >>>>>>> This issue fix patch has been merged into main, But it has >>>>>>> not backported >>>>> to 22.11.3. >>>>>>> Fix patch commit id on DPDK main: >>>>>>> 7e7b6762eac292e78c77ad37ec0973c0c944b845 >>>>>>> >>>>>>> 2. The SCTP tunnel packet of iavf cannot be forwarded in avx512 >>>>>>> mode >>>>> >>>>> Need to clarify this sentence. It looks like it is not a functional >>>>> bug where >>>>> avx512 mode is selected and then an SCTP tunnel packet cannot be sent. >>>>> Instead, it is a possible performance issue that avx512 mode will >>>>> not be selected where it might have been due to unneeded additions >>>>> (RTE_ETH_TX_OFFLOAD_*_TNL_TSO) to IAVF_TX_NO_VECTOR_FLAGS. >>>>> >>>>> @IAVF maintainers - please confirm my analysis is correct ? >>>>> >>>>> In that case, as it is a possible performance issue in a specific >>>>> case for a single driver I think it is non-critical for 21.11 and we >>>>> can just revert the patch on the branch and wait for 21.11.6 release in >> December. >>>> >>>> Hi Kevin, >>>> >>>> Since the LTS version of the IAVF driver does not support avx512 >>>> checksum offload, the scalar path should be selected, but this patch >>>> makes it incorrectly select the >>>> avx512 path, and the SCTP tunnel packets can't be forwarded properly. >>>> >>> >>> ok, let's take a look at the patch and usage. >>> >>> diff --git a/drivers/net/iavf/iavf_rxtx.h >>> b/drivers/net/iavf/iavf_rxtx.h index 8d4a77271a..605ea3f824 100644 >>> --- a/drivers/net/iavf/iavf_rxtx.h >>> +++ b/drivers/net/iavf/iavf_rxtx.h >>> @@ -32,4 +32,8 @@ >>> RTE_ETH_TX_OFFLOAD_MULTI_SEGS | \ >>> RTE_ETH_TX_OFFLOAD_TCP_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_SECURITY) >>> >>> >>> >>> So we now have: >>> #define IAVF_TX_NO_VECTOR_FLAGS ( \ >>> RTE_ETH_TX_OFFLOAD_VLAN_INSERT | \ >>> RTE_ETH_TX_OFFLOAD_QINQ_INSERT | \ >>> RTE_ETH_TX_OFFLOAD_MULTI_SEGS | \ >>> RTE_ETH_TX_OFFLOAD_TCP_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_SECURITY) >>> >>> >>> > > Hi Kevin, > > This patch also removes two flags from IAVF_TX_NO_VECTOR_FLAGS, RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM > and RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM. > >>> static inline int >>> iavf_tx_vec_queue_default(struct iavf_tx_queue *txq) { >>> if (!txq) >>> return -1; >>> >>> if (txq->rs_thresh < IAVF_VPMD_TX_MAX_BURST || >>> txq->rs_thresh > IAVF_VPMD_TX_MAX_FREE_BUF) >>> return -1; >>> >>> if (txq->offloads & IAVF_TX_NO_VECTOR_FLAGS) >>> return -1; >>> ^^^ Adding the extra bits to IAVF_TX_NO_VECTOR_FLAGS >>> gives >>> *more* reasons for why this statement might not be true, so returning >>> -1 indicating that vector cannot be used for tx queue >>> >> >> typo here - just to clarify, the new flags give more reasons for this statement >> to be true, so returning -1. >> >>> >>> >>> >>> static inline bool >>> check_tx_vec_allow(struct iavf_tx_queue *txq) { >>> if (!(txq->offloads & IAVF_TX_NO_VECTOR_FLAGS) && >>> >>> ^^^ Adding the extra bits to IAVF_TX_NO_VECTOR_FLAGS >>> gives >>> *more* reason for this statement will be false and then false returned >>> indicating that vector cannot be used. >>> >>> txq->rs_thresh >= IAVF_VPMD_TX_MAX_BURST && >>> txq->rs_thresh <= IAVF_VPMD_TX_MAX_FREE_BUF) { >>> PMD_INIT_LOG(DEBUG, "Vector tx can be enabled on this >> txq."); >>> return true; >>> } >>> PMD_INIT_LOG(DEBUG, "Vector Tx cannot be enabled on this txq."); >>> return false; >>> } >>> >>> -- >>> >>> It looks like that adding the extra bits gives it less reasons to >>> select vector mode. However, you are saying that this patch means >>> there is a case where it now selects vector where it should not, >>> meaning additional reason to select vector mode. So maybe I miss >> something ? > > Originally, the vector path would not be selected after configuring outer checksum offload, > but it will be selected after removing the two flags. > But the vector path doesn't support outer checksum offload on stable DPDK, so there will be a problem. > > The key issue is that these two flags are removed, RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM > and RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM. > ok, i got it now. In the main branch (ca34627be5d6) and the 21.11 backport (3eb4ad8ed694) those flags are not removed. Those flags are only removed in the 22.11 branch (9b7215f150d0). So this is not an issue for 21.11. Thanks for helping clear it up. Kevin. > Regards > Zhichao > >>> >>>> Yes, we can revert this commit for 21.11.6 release, thanks. >>>> >>>> Regards >>>> Zhichao >>>> >>>>> thanks, >>>>> Kevin. >>>>> >>>>>>> commit 9b7215f150d0bfc5cb00fce68ff08e5217c7f2b3 on >> v22.11.3- >>>>> rc1. >>>>>>> This commit is for the new feature (avx512 checksum offload) >>>>>>> in DPDK >>>>> 23.03, which should not be backported to the LTS version since >>>>> avx512 checksum offload is not supported in v22.11.3 LTS. >>>>>>> >>>>>> >>>>>> Thanks for flagging Xueming. >>>>>> >>>>>> The issue is that it was listed as fixing 059f18ae2aec ("net/iavf: >>>>>> add offload path for Tx AVX512") which goes back to 21.05. >>>>>> >>>>>> This could have been avoided if the 'Fixes:' tag was correct, or if >>>>>> the authors replied to the email about queued backports :/ >>>>>> >>>>>> Requesting iavf/next-net-intel maintainers to check Fixes: tags are >>>>>> correct before merging. >>>>>> >>>>>> DPDK 21.11.5 is already released with this patch. Any idea why it >>>>>> did not show up in validation for 21.11.5 ? Is it an issue for 21.11.5 ? >>>>>> How critical is it ? >>>>>> >>>>>> I can revert it on the 21.11 branch, but it will need to wait until >>>>>> 21.11.6 in December before it will be reverted in a released version. >>>>>> >>>>>> thanks, >>>>>> Kevin. >>>>>> >>>>>>> Regards, >>>>>>> Xu, Hailin >>>>>>> >>>>>> >>>> >>> >