patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Kevin Traynor <ktraynor@redhat.com>
To: "Xueming(Steven) Li" <xuemingl@nvidia.com>,
	"Wang, Haiyue" <haiyue.wang@intel.com>,
	Luca Boccassi <bluca@debian.org>,
	"stable@dpdk.org" <stable@dpdk.org>
Cc: NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	"christian.ehrhardt@canonical.com"
	<christian.ehrhardt@canonical.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>
Subject: Re: [dpdk-stable] [PATCH 20.11 v2 00/18] Backport the new VLAN design for Intel ice PMD
Date: Thu, 17 Jun 2021 11:04:44 +0100	[thread overview]
Message-ID: <30bf553b-032c-d992-487f-794cbe1816fe@redhat.com> (raw)
In-Reply-To: <DM4PR12MB53731886CCE59AD12E7476DFA10E9@DM4PR12MB5373.namprd12.prod.outlook.com>

On 17/06/2021 09:53, Xueming(Steven) Li wrote:
> Hi Haiyue,
> 
>> -----Original Message-----
>> From: Wang, Haiyue <haiyue.wang@intel.com>
>> Sent: Thursday, June 17, 2021 9:16 AM
>> To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
>> Cc: Xueming(Steven) Li <xuemingl@nvidia.com>; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
>> christian.ehrhardt@canonical.com; ktraynor@redhat.com; Zhang, Qi Z <qi.z.zhang@intel.com>
>> Subject: RE: [dpdk-stable] [PATCH 20.11 v2 00/18] Backport the new VLAN design for Intel ice PMD
>>
>>> -----Original Message-----
>>> From: Luca Boccassi <bluca@debian.org>
>>> Sent: Wednesday, June 16, 2021 23:47
>>> To: Wang, Haiyue <haiyue.wang@intel.com>; stable@dpdk.org
>>> Cc: xuemingl@nvidia.com; thomas@monjalon.net;
>>> christian.ehrhardt@canonical.com; ktraynor@redhat.com; Zhang, Qi Z
>>> <qi.z.zhang@intel.com>
>>> Subject: Re: [dpdk-stable] [PATCH 20.11 v2 00/18] Backport the new
>>> VLAN design for Intel ice PMD
>>>
>>> On Fri, 2021-06-11 at 15:15 +0800, Haiyue Wang wrote:
>>>> When LTS 20.11 was released, the Intel ice PMD has a basic VLAN
>>>> offload, which can only handle single VLAN mode for firmware
>>>> limitation. Now the firmware is updated to support double VLAN mode
>>>> and single VLAN mode at the same time. It depends on the driver to do selection at the boot time.
>>>>
>>>> As VLAN protocol handling like strip, filter, flow is very common
>>>> use, we request to support the ice PMD can run on the latest
>>>> firmware for enabling the new design. This is compatible backport as the main tree.
>>>>
>>>> v2: Fix the subject fix with messy code like : PATCHÂ
>>>>
>>>> Haiyue Wang (4):
>>>>   net/ice/base: do not set VLAN mode in DCF mode
>>>>   net/ice: fix VLAN strip for double VLAN
>>>>   net/ice: fix VLAN 0 adding based on VLAN mode
>>>>   net/ice: update QinQ switch filter handling
>>>>
>>>> Junfeng Guo (1):
>>>>   net/ice: enable QinQ filter for switch
>>>>
>>>> Qi Zhang (12):	
>>>>   net/ice/base: align add VSI and update VSI AQ command buffer
>>>>   net/ice/base: add interface to support configuring VLAN mode
>>>>   net/ice/base: fix outer VLAN related macro
>>>>   net/ice/base: add VLAN TPID for VLAN filters
>>>>   net/ice/base: support checking double VLAN mode
>>>>   net/ice/base: support configuring device in double VLAN mode
>>>>   net/ice/base: update boost TCAM for DVM
>>>>   net/ice/base: change protocol ID for VLAN in DVM
>>>>   net/ice/base: refactor post DDP download VLAN mode config
>>>>   net/ice/base: log if DDP/FW do not support QinQ
>>>>   net/ice/base: add inner VLAN protocol type for QinQ filter
>>>>   net/ice/base: fix QinQ PPPoE dummy packet selection
>>>>
>>>> Yuying Zhang (1):
>>>>   net/ice/base: add ethertype offset for QinQ dummy packet
>>>>
>>>>  drivers/net/ice/base/ice_adminq_cmd.h    | 268 ++++++++-----
>>>>  drivers/net/ice/base/ice_bitops.h        |  45 +++
>>>>  drivers/net/ice/base/ice_common.c        |  38 ++
>>>>  drivers/net/ice/base/ice_common.h        |   4 +
>>>>  drivers/net/ice/base/ice_flex_pipe.c     | 302 +++++++++++++--
>>>>  drivers/net/ice/base/ice_flex_pipe.h     |  12 +
>>>>  drivers/net/ice/base/ice_flex_type.h     |  39 ++
>>>>  drivers/net/ice/base/ice_protocol_type.h |   1 +
>>>>  drivers/net/ice/base/ice_switch.c        | 124 +++++-
>>>>  drivers/net/ice/base/ice_switch.h        |  15 +
>>>>  drivers/net/ice/base/ice_type.h          |   4 +
>>>>  drivers/net/ice/base/ice_vlan_mode.c     | 451 ++++++++++++++++++++++
>>>>  drivers/net/ice/base/ice_vlan_mode.h     |  16 +
>>>>  drivers/net/ice/base/meson.build         |   1 +
>>>>  drivers/net/ice/ice_ethdev.c             | 455 +++++++++++++----------
>>>>  drivers/net/ice/ice_ethdev.h             |  10 +-
>>>>  drivers/net/ice/ice_generic_flow.c       |   8 +
>>>>  drivers/net/ice/ice_generic_flow.h       |   1 +
>>>>  drivers/net/ice/ice_switch_filter.c      | 114 +++++-
>>>>  19 files changed, 1545 insertions(+), 363 deletions(-)  create mode
>>>> 100644 drivers/net/ice/base/ice_vlan_mode.c
>>>>  create mode 100644 drivers/net/ice/base/ice_vlan_mode.h
>>>
>>> Hi,
>>>
>>> At 1.9k diffstat, this series is quite large. Given it's a new
>>> feature, rather than a series of bug fixes, this would seem a bit risky to me.
>>> Final word of course belongs to Xueming, since he's managing this one.
>>> See:
>>>
>>

Thanks for using the questions as a way to discuss it, it is a good way
to see if they are useful. Just to note, they were to try and capture
some of the important things for a maintainer to consider, it is not a
flow chart leading to a binary answer (though clearly some things like
ABI breakage, probably would end the discussion).

>> 01. Does the feature break API/ABI?
>>
>>  NO.
>>
>> 02. Does the feature break backwards compatibility?
>>
>>  NO.
>>
>> 03. Is it for the latest LTS release (to avoid LTS upgrade issues)?
>>
>> Yes.
>>
>> 04. Is there a commitment from the proposer or affiliation to validate the feature and check for regressions in related functionality?
>>
>> Passed internally, if needed, an official Test-by can be provided.
>>

It would be better to share test cases (even high level), not just a
tested-by which doesn't give any idea of test coverage.

I would look at it like:
The new functionality not working with the new firmware and new code is
not a big issue.

The old functionality not working with the new firmware and the new code
is a big issue.

The old functionality not working with the old firmware and the new code
is a very big issue.

So regression testing of the old functionality would be the most
important IMHO.

>> 05. Is there a track record of the proposer or affiliation validating stable releases?
>>

Yes, Intel tests every LTS release.

>> Bugzilla ?
>>
>> 06. Is it obvious that the feature will not impact existing functionality?
>>
>> Yes.
>>

No. It is 1.9KLOC change. The key part of the question is "obvious". It
was meant so the maintainer could use their judgement and review that
for example, a few lines of code adding a PCI ID or adding a case in a
switch statement, is obviously not going to impact existing functionality.

On the other hand, for a more complex code change to existing code, it
is not immediately obvious that there would be no risk to existing
functionality.

>> 07. How intrusive is the code change?
>>
>>  From LOC, yes, 1.9K seems to be BIG, but DPDK PMD related is 588, other is  the share code in base (1320), which is tested and
>> validated on other platform.
>>

Very intrusive. It seems to be big, because it is big.

>>      drivers/net/ice/ice_ethdev.c             | 455 +++++++++++++----------
>>      drivers/net/ice/ice_ethdev.h             |  10 +-
>>      drivers/net/ice/ice_generic_flow.c       |   8 +
>>      drivers/net/ice/ice_generic_flow.h       |   1 +
>>      drivers/net/ice/ice_switch_filter.c      | 114 +++++-
>>
>> 08. What is the scope of the code change?
>>
>> PMD only.
>>
>> 09. Does it impact common components or vendor specific?
>>
>> NO.
>>
>> 10. Is there a justifiable use case (a clear user need)?
>>
>> Yes, for firmware updated. And we have the customer who wants to use the VLAN feature on LTS 20.11.
>>

Well, like a lot of the considerations, this is subjective and everyone
will think there is a need for their own patches, that is a given. It is
for the maintainer to try and balance the need of the feature against
the possible impacts to the LTS.

It seems like you mentioned "for updated firmware" and "customer who
wants to used the VLAN feature" as separate points. If there is a
separate need for updating firmware aside from new VLAN functionality,
it is good to state that.

>> 11. Is there a community consensus about the backport?
>>
>> ...
> 
> Kevin happens to updated the documents on new feature backport 4 months ago, thanks for checking them 
> one by one. Luca's only concern is size of the series, driver vendor is on it's own risk to backport a big patch set.
> The series supports new fw and QinQ, is it easy to split?
> 
> Kevin, is this the first case of feature backport? How do you think?
> 

Like Luca, main concern would be the size and intrusiveness of the
changes, and if it's ok to change 1.9KLOC in this driver now, then why
not 20KLOC in next release to multiple drivers. I had pushed against a
LOC limit when this was last discussed at the TB, as it's a crude way to
judge code complexity/risk, but maybe it should be considered.

On the positive side it is self-contained and Intel has an excellent
track record for testing LTS.

>>
>>> https://doc.dpdk.org/guides/contributing/stable.html#what-changes-shou
>>> ld-be-backported
>>>
>>> --
>>> Kind regards,
>>> Luca Boccassi


  reply	other threads:[~2021-06-17 10:04 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11  6:58 [PATCH 20.11 v1 " Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 01/18] net/ice/base: align add VSI and update VSI AQ command buffer Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 02/18] net/ice/base: add interface to support configuring VLAN mode Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 03/18] net/ice/base: fix outer VLAN related macro Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 04/18] net/ice/base: add VLAN TPID for VLAN filters Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 05/18] net/ice/base: support checking double VLAN mode Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 06/18] net/ice/base: support configuring device in " Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 07/18] net/ice/base: do not set VLAN mode in DCF mode Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 08/18] net/ice/base: update boost TCAM for DVM Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 09/18] net/ice/base: change protocol ID for VLAN in DVM Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 10/18] net/ice/base: refactor post DDP download VLAN mode config Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 11/18] net/ice/base: log if DDP/FW do not support QinQ Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 12/18] net/ice/base: add ethertype offset for QinQ dummy packet Haiyue Wang
2021-06-11  6:58 ` [PATCH 20.11 v1 13/18] net/ice/base: add inner VLAN protocol type for QinQ filter Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 14/18] net/ice/base: fix QinQ PPPoE dummy packet selection Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 15/18] net/ice: fix VLAN strip for double VLAN Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 16/18] net/ice: fix VLAN 0 adding based on VLAN mode Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 17/18] net/ice: enable QinQ filter for switch Haiyue Wang
2021-06-11  6:58 ` [dpdk-stable] [PATCH 20.11 v1 18/18] net/ice: update QinQ switch filter handling Haiyue Wang
2021-06-11  7:15 ` [dpdk-stable] [PATCH 20.11 v2 00/18] Backport the new VLAN design for Intel ice PMD Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 01/18] net/ice/base: align add VSI and update VSI AQ command buffer Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 02/18] net/ice/base: add interface to support configuring VLAN mode Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 03/18] net/ice/base: fix outer VLAN related macro Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 04/18] net/ice/base: add VLAN TPID for VLAN filters Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 05/18] net/ice/base: support checking double VLAN mode Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 06/18] net/ice/base: support configuring device in " Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 07/18] net/ice/base: do not set VLAN mode in DCF mode Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 08/18] net/ice/base: update boost TCAM for DVM Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 09/18] net/ice/base: change protocol ID for VLAN in DVM Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 10/18] net/ice/base: refactor post DDP download VLAN mode config Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 11/18] net/ice/base: log if DDP/FW do not support QinQ Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 12/18] net/ice/base: add ethertype offset for QinQ dummy packet Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 13/18] net/ice/base: add inner VLAN protocol type for QinQ filter Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 14/18] net/ice/base: fix QinQ PPPoE dummy packet selection Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 15/18] net/ice: fix VLAN strip for double VLAN Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 16/18] net/ice: fix VLAN 0 adding based on VLAN mode Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 17/18] net/ice: enable QinQ filter for switch Haiyue Wang
2021-06-11  7:15   ` [dpdk-stable] [PATCH 20.11 v2 18/18] net/ice: update QinQ switch filter handling Haiyue Wang
2021-06-16 15:47   ` [dpdk-stable] [PATCH 20.11 v2 00/18] Backport the new VLAN design for Intel ice PMD Luca Boccassi
2021-06-17  1:16     ` Wang, Haiyue
2021-06-17  8:53       ` Xueming(Steven) Li
2021-06-17 10:04         ` Kevin Traynor [this message]
2021-06-18  3:22           ` Wang, Haiyue
2021-06-18 10:12             ` Kevin Traynor
2021-06-18 11:46               ` Wang, Haiyue
2021-06-21  8:28             ` Thomas Monjalon
2021-06-21  8:34               ` Wang, Haiyue
2021-06-21  8:59                 ` Kevin Traynor
2021-06-21 10:28               ` Kevin Traynor
2021-06-22  1:41                 ` Wang, Haiyue
2021-06-18  1:56         ` Wang, Haiyue
2021-06-20 13:47           ` Xueming(Steven) Li
2021-06-21  1:35             ` Wang, Haiyue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30bf553b-032c-d992-487f-794cbe1816fe@redhat.com \
    --to=ktraynor@redhat.com \
    --cc=bluca@debian.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=haiyue.wang@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=xuemingl@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).