From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 764BBA04B1 for ; Tue, 24 Nov 2020 15:28:03 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6EE28C936; Tue, 24 Nov 2020 15:28:02 +0100 (CET) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by dpdk.org (Postfix) with ESMTP id 64C80C936 for ; Tue, 24 Nov 2020 15:27:59 +0100 (CET) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4CgRDx6LHtzLs2b; Tue, 24 Nov 2020 22:27:29 +0800 (CST) Received: from [10.67.103.119] (10.67.103.119) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.487.0; Tue, 24 Nov 2020 22:27:49 +0800 To: Luca Boccassi , CC: References: <1605274630-23414-1-git-send-email-oulijun@huawei.com> <18a6430d79fd41752f54ec79d73404b9c69d0914.camel@debian.org> From: oulijun Message-ID: <2b8e45e6-5764-8ec6-bf71-37644ea2193b@huawei.com> Date: Tue, 24 Nov 2020 22:27:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <18a6430d79fd41752f54ec79d73404b9c69d0914.camel@debian.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.119] X-CFilter-Loop: Reflected Subject: Re: [dpdk-stable] [PATCH 19.11.6 00/13] backport for 19.11.6 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 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 Sender: "stable" 在 2020/11/23 23:52, Luca Boccassi 写道: > On Fri, 2020-11-13 at 21:36 +0800, Lijun Ou wrote: >> Hi, Luca Boccassi >> His series are backport for 19.11.6 about hns3 PMD driver >> I also noticed that you gave Hu Wei a suggestion on the 19.11.4 >> backport. You did not recommend adding new features. I reselected >> the TSO and some performance optimization patch request backports. >> The reason I do this is that I think TSO is also a performance >> optimization point, including other fixes. In addition, if TSO >> is not integrated, the bug fixes of the cksum may not be integrated, >> which will cause the stability of the cksum function. >> >> Chengchang Tang (5): >> net/hns3: support promiscuous and allmulticast mode for VF >> net/hns3: decrease non-nearby memory access in Rx >> net/hns3: cleanup duplicated code on processing TSO in Tx >> net/hns3: fix Tx checksum outer header prepare >> net/hns3: fix Tx checksum with fixed header length >> >> Hongbo Zheng (1): >> net/hns3: check TSO segment size during Tx >> >> Lijun Ou (2): >> net/hns3: support TSO >> net/hns3: report Tx descriptor segment limitations >> >> Wei Hu (Xavier) (5): >> net/hns3: fix reassembling multiple segment packets in Tx >> net/hns3: fix inserted VLAN tag position in Tx >> net/hns3: report Rx drop packets enable configuration >> net/hns3: report Rx free threshold >> net/hns3: reduce address calculation in Rx >> >> doc/guides/nics/features/hns3.ini | 1 + >> doc/guides/nics/features/hns3_vf.ini | 3 + >> doc/guides/nics/hns3.rst | 1 + >> drivers/net/hns3/hns3_ethdev.c | 38 +- >> drivers/net/hns3/hns3_ethdev.h | 37 +- >> drivers/net/hns3/hns3_ethdev_vf.c | 134 ++++++- >> drivers/net/hns3/hns3_mbx.c | 23 ++ >> drivers/net/hns3/hns3_mbx.h | 2 + >> drivers/net/hns3/hns3_rxtx.c | 666 ++++++++++++++++++++++++----------- >> drivers/net/hns3/hns3_rxtx.h | 31 +- >> 10 files changed, 720 insertions(+), 216 deletions(-) > > Hi, > > I discussed this proposal with other maintainers, and I'm afraid the > original answer still stands - we feel backporting an entire new > offload is too much for the scope of an LTS release. > > While sometimes we do allow for some featurettes to be backported, in > the form of a new #define or such small changes, there was consensus > that a 936 lines diff is too much churn for what is expected from a > stable release, which is stability. The risk of introducing new bugs, > especially in face of the fact that we never had regression tests > coverage for the hns3 PMD for LTSes before, is too high. > > The 20.05/20.08 releases are ABI compatible with 19.11, so if there's > an urgent need for this feature in users of the hns3 PMD, one of those > can be used instead. Some other companies also maintain downstream > trees of the LTSes with invasive changes to their PMDs, that are deemed > too risky for the upstream tree, so that's another option available to > you. > > Sorry! > I see. Can I re-split the bugfix of the TSO part based on the patch and return it to you? Thanks Lijun Ou