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 47901424F1 for ; Mon, 4 Sep 2023 16:15:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4E0604069F; Mon, 4 Sep 2023 16:15:33 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 9416B40691 for ; Mon, 4 Sep 2023 16:15:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693836931; 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=3rAlzN4yqKiUBcZhS3FF3KFxi9NFlZ8NV9uXJU7DKYs=; b=IuZpZSQRnlPsXY2jr+OpNOYOy/+LWOi/9ADdkZLJNjPbybbwPzb6+6/zdncvGBXbpobLW2 mFykf7CjKSFwU+I48gQt1rEEM3CG5jGzA3eKbmUL0wIEfS+XjbI1yK1uNLqfyYT96n3s78 KW+liQZNKQIwgSlRiEZeVqHkexoHTmk= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-624-6oVZJ2JUOb-_9Xqa915JqA-1; Mon, 04 Sep 2023 10:15:30 -0400 X-MC-Unique: 6oVZJ2JUOb-_9Xqa915JqA-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-402cd372b8bso7350085e9.2 for ; Mon, 04 Sep 2023 07:15:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693836929; x=1694441729; h=content-transfer-encoding:in-reply-to:subject:references:cc:to:from :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3rAlzN4yqKiUBcZhS3FF3KFxi9NFlZ8NV9uXJU7DKYs=; b=Otpu91Y9j6xNud7/jGejNeJInYCXqDc+YeItUHuqYrOxsyXDkuyjn/6QqgMbwLnHHG RkXZ/7OSWLFOzfnN3j20ICiJaInNXCDJiFUoay2rVhnz0fRlIvtgaVQpY+TMpOIPonhJ Pu83/iAY9W5nPbZ7djDolrtQ8hl4V/Ek8HOOC4sN7fG0nh8hvuTSiViJTtZ2gZU1s0Gq r6WJjN+g4lXMCGt41q59e3jgE69jKjxyFRI98+PwxoM3HPBKEQNmnbVfBjPF8QekiGFr mvP0FJMoqYFXNAOuCw1euNxK+SGkH0464iPIYtbrTeQP7MfOcS5LhHVMmJAqPr8Rm7C0 4ndg== X-Gm-Message-State: AOJu0Yw8cCznOawKdQvhsboj3GNeaJnXAxoblOXlfARw1Kq4Wf0inm3k pVdg8ENnuZyx3Bq28Ne4duVfaDxGwNhcEwq0tRd94Izc0fLLngMRtKQBm2BGNLAP9SmhDr0WMc4 fxAIJr9Q= X-Received: by 2002:a7b:c4c7:0:b0:401:b1c6:97eb with SMTP id g7-20020a7bc4c7000000b00401b1c697ebmr6925657wmk.27.1693836928909; Mon, 04 Sep 2023 07:15:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH3lCq5OoSgJEXWYlKAL1FLuXi53fNj3GEjgJWRgZFibzLGoN6icoqCrydpshGbZ3/WBN/QgA== X-Received: by 2002:a7b:c4c7:0:b0:401:b1c6:97eb with SMTP id g7-20020a7bc4c7000000b00401b1c697ebmr6925644wmk.27.1693836928505; Mon, 04 Sep 2023 07:15:28 -0700 (PDT) Received: from [192.168.0.36] ([78.19.106.24]) by smtp.gmail.com with ESMTPSA id m12-20020adff38c000000b0031ad5fb5a0fsm14618108wro.58.2023.09.04.07.15.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Sep 2023 07:15:27 -0700 (PDT) Message-ID: <307bf0a5-b0a6-b602-64b8-8eff3dcf3905@redhat.com> Date: Mon, 4 Sep 2023 15:15:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 From: Kevin Traynor 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" References: <20230817061332.16248-1-xuemingl@nvidia.com> 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: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org 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) > > > > 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 ? > >> 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 >>>>> >>>> >> >