[dpdk-stable] [PATCH 20.11 v2 00/18] Backport the new VLAN design for Intel ice PMD

[Kevin Traynor]

On 17/06/2021 09:53, Xueming(Steven) Li wrote:
> Hi Haiyue,
> 
>> -----Original Message-----
>> From: Wang, Haiyue <haiyue.wang at intel.com>
>> Sent: Thursday, June 17, 2021 9:16 AM
>> To: Luca Boccassi <bluca at debian.org>; stable at dpdk.org
>> Cc: Xueming(Steven) Li <xuemingl at nvidia.com>; NBU-Contact-Thomas Monjalon <thomas at monjalon.net>;
>> christian.ehrhardt at canonical.com; ktraynor at redhat.com; Zhang, Qi Z <qi.z.zhang at 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 at debian.org>
>>> Sent: Wednesday, June 16, 2021 23:47
>>> To: Wang, Haiyue <haiyue.wang at intel.com>; stable at dpdk.org
>>> Cc: xuemingl at nvidia.com; thomas at monjalon.net;
>>> christian.ehrhardt at canonical.com; ktraynor at redhat.com; Zhang, Qi Z
>>> <qi.z.zhang at 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