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

[Wang, Haiyue]

> -----Original Message-----
> From: Kevin Traynor <ktraynor at redhat.com>
> Sent: Monday, June 21, 2021 18:28
> To: Thomas Monjalon <thomas at monjalon.net>; Xueming(Steven) Li <xuemingl at nvidia.com>; Luca Boccassi
> <bluca at debian.org>; Wang, Haiyue <haiyue.wang at intel.com>; christian.ehrhardt at canonical.com
> Cc: stable at dpdk.org; Zhang, Qi Z <qi.z.zhang at intel.com>; Fu, Qi <qi.fu at intel.com>; techboard at dpdk.org
> Subject: Re: [dpdk-stable] [PATCH 20.11 v2 00/18] Backport the new VLAN design for Intel ice PMD
> 
> 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.

Yes, they love LTS.

> 
> 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.

In my eyes, it not a BIG feature, just very simple VLAN design changed. The
BIG you mentioned is LOC. ;-)

We are OK if you don't like code change so much.