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

[Kevin Traynor]

On 21/06/2021 09:28, Thomas Monjalon wrote:
> 18/06/2021 05:22, Wang, Haiyue:
>> From: Kevin Traynor <ktraynor at redhat.com>
>>> On 17/06/2021 09:53, Xueming(Steven) Li wrote:
>>>> From: Wang, Haiyue <haiyue.wang at intel.com>
>>>>> From: Luca Boccassi <bluca at debian.org>
>>>>>> 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.
> [...]
>>>>>>>  19 files changed, 1545 insertions(+), 363 deletions(-)  create mode
> [...]
>>>>>> 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.
> 
> [...]
>>>>> 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.
> 
> [...]
>>>>> 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
>>
>> TBH, we won't want to change the stable i40e, ixgbe PMDs, but ice is a fresh
>> one, current VLAN has a limited usage, customer is hard to use. That's why we
>> try to request to backport the new VLAN design.
> 
> Yes ice is quite recent.
> If a required feature is not working, it should motivate to upgrade.
> Because ice is "fresh", I don't understand why sticking to 20.11.
> My concern is that backporting this big feature would create a precedent,
> so all users will require to stick on the last LTS when getting
> all the new reworked features.
> I think it would be a bad situation for all of us.
> 
> 
> 

Why can't the users use ABI compatible 21.02/21.05? Why do they want to
stay on 20.11? The only reason I can see for staying on 20.11 is because
it is a stable (bug fix only) release.

So you want an LTS that is bug fix only except for ice with new features.

A type of LTS-main hybrid for selected drivers seems like something more
suited for individual vendors and not replacing the community LTS with IMHO.

But if it were to replace the current community LTS, or become the
normal, then it should be consciously decided. I feel doing it by adding
one big feature at a time to the current LTS is not the right approach.