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 6BA24A04B1 for ; Mon, 23 Nov 2020 16:52:50 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5CE50C8C6; Mon, 23 Nov 2020 16:52:49 +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 6F6AFC8C6 for ; Mon, 23 Nov 2020 16:52:47 +0100 (CET) Received: by mail-wm1-f68.google.com with SMTP id h21so17695662wmb.2 for ; Mon, 23 Nov 2020 07:52:47 -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=iig5lNrN/yY56dg0aPZov9J8GFEd2tg4O+DkE5wKqmk=; b=bgSTkI3HCZXRV8Twd541B7G1s+cHMnnq2zOOXzozZ852OlvPhL0Yo+CA/uh7qxYUUU FJevGFyoSn8HPaHl0lsH3i2Kg6cBfPqjvn8ewkJOYmubPkTh8taQPscCL4hhCtjStAFV ib5Dk4Jn9YJ9TC5rVn4gC9Pt/7VPOHwkr72D+0fXTqGB9ez9nn43kIkgQpUp6APOH672 HlJjbIGdqZxurjYYB9jCIbvyk6bdxTWHdKRIkqhHnZ5kZN+8CR3LDJnqTa9GVnlKpeeb VDo9PSgMr2tEmyEDWKeNUvD88YOV2sz+XIfJ4mTn/Kqgo6PKotxu1DaYYlNLsLl9/HDA zVNg== X-Gm-Message-State: AOAM532LplH0QhZ38yZPAoENE0gC8UTwWsoSMQn41+aZbvLRORGnUrd9 USxfAV8eC63j2tmPyE7gxag= X-Google-Smtp-Source: ABdhPJz8CJezx434QpXCwx2JO3tknU627Lu51viKJLfQj2D3quRh3JP2NeQJ92yOV+h7McBiJkfOVA== X-Received: by 2002:a05:600c:ce:: with SMTP id u14mr24345042wmm.32.1606146766128; Mon, 23 Nov 2020 07:52:46 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id b8sm16837166wmj.9.2020.11.23.07.52.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Nov 2020 07:52:45 -0800 (PST) Message-ID: <18a6430d79fd41752f54ec79d73404b9c69d0914.camel@debian.org> From: Luca Boccassi To: Lijun Ou , stable@dpdk.org Cc: linuxarm@huawei.com Date: Mon, 23 Nov 2020 15:52:44 +0000 In-Reply-To: <1605274630-23414-1-git-send-email-oulijun@huawei.com> References: <1605274630-23414-1-git-send-email-oulijun@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 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(-) 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! --=20 Kind regards, Luca Boccassi