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 B2B4CA04B1 for ; Tue, 24 Nov 2020 16:35:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AA8AEC926; Tue, 24 Nov 2020 16:35:27 +0100 (CET) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 83229C926 for ; Tue, 24 Nov 2020 16:35:25 +0100 (CET) Received: by mail-wm1-f68.google.com with SMTP id p19so2284920wmg.0 for ; Tue, 24 Nov 2020 07:35:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=G9Ynv+PDX9J7l7MoQvnOnMQNNTeTGD6sRadWk75WPvg=; b=M3B2ux41Leayh4QdMtUIv9X16bAC/GcACdPxeEWr3z0Pr//wFenVPhgl953oN7Dh08 OLkL5V7fR/4wf2hTGiE/9X3XWhhfhb1mGBqIxZXIyZZr4psWznYl3TINKmS9adiD76RV EtnM0A+/wlDO2CZJDxGLOR7EUK8kfAH6Fq9HaXD9tiew+kp8/VXz+Bvx4zWIq+sUF6le yczO1ouXuImJcpS3d3y/MRTMRBxM+PuriMc/aBkG9hGLLGe/N03WmIy/OUl4nYEgsdwN bHBJ34d/czOPrTU1U75aEpXgV7NYOoOfI55z+wRllIy+D/72bNxvQZfAFml6ik84XheA Fr2w== X-Gm-Message-State: AOAM531CbCAU3mRxyy0Vl5Il20DeW4agsODRL8lOCeYcmh4yKr8sAbeU qHj0jVk1ggEGWg7yCF0M2CU= X-Google-Smtp-Source: ABdhPJzJjSoX+pjL151lsRmgTLVShLWSyXZQM22c1PYxArxJ5uNrj0Bu1AmqkuL8WZ7q9iIpF/74hw== X-Received: by 2002:a05:600c:ce:: with SMTP id u14mr5128756wmm.32.1606232125219; Tue, 24 Nov 2020 07:35:25 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id e27sm11849563wrc.9.2020.11.24.07.35.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Nov 2020 07:35:24 -0800 (PST) Message-ID: From: Luca Boccassi To: oulijun , stable@dpdk.org Cc: linuxarm@huawei.com Date: Tue, 24 Nov 2020 15:35:23 +0000 In-Reply-To: <2b8e45e6-5764-8ec6-bf71-37644ea2193b@huawei.com> References: <1605274630-23414-1-git-send-email-oulijun@huawei.com> <18a6430d79fd41752f54ec79d73404b9c69d0914.camel@debian.org> <2b8e45e6-5764-8ec6-bf71-37644ea2193b@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 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" On Tue, 2020-11-24 at 22:27 +0800, oulijun wrote: >=20 > =E5=9C=A8 2020/11/23 23:52, Luca Boccassi =E5=86=99=E9=81=93: > > 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. > > >=20 > > > 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 > > >=20 > > > Hongbo Zheng (1): > > > net/hns3: check TSO segment size during Tx > > >=20 > > > Lijun Ou (2): > > > net/hns3: support TSO > > > net/hns3: report Tx descriptor segment limitations > > >=20 > > > 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 > > >=20 > > > 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(-) > >=20 > > Hi, > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > Sorry! > >=20 > I see. Can I re-split the bugfix of the TSO part based on the patch and= =20 > return it to you? >=20 > Thanks > Lijun Ou Yes, certainly, individual bug fixes are always welcome. Thanks! --=20 Kind regards, Luca Boccassi