RE: [PATCH v3] net/iavf: revert fix VLAN insertion

["Zhang, Qi Z" <qi.z.zhang@intel.com>]

> -----Original Message-----
> From: Zhou, YidingX <yidingx.zhou@intel.com>
> Sent: Thursday, November 10, 2022 10:10 AM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; dev@dpdk.org
> Cc: ktraynor@redhat.com; Yang, Qiming <qiming.yang@intel.com>
> Subject: RE: [PATCH v3] net/iavf: revert fix VLAN insertion
> 
> > > Subject: [PATCH v3] net/iavf: revert fix VLAN insertion
> > >
> > > The vector Tx path does not support VLAN insertion via the L2TAG2
> > > field, but the scalar path supports. The previous commit was to
> > > force to select scalar path as soon as kernel driver requests to use L2TAG2.
> >
> > In which situation, that kernel driver will request to use L2TAG2?
> 
> According to my tests, this happens when the kernel driver version is newer
> than 1.8.9

> 
> > >
> > > That logic is incorrect. Because other case like VLAN offloading not
> > > required but scalar path selected would have a significant performance
> drop .
> > > Therefore the following commit needs to revert.
> >
> > What will happen, if kernel driver request to use L2TAG2, but still
> > vector path is selected?
> >
> The VLAN tag will be inserted to wrong location (inner of QinQ),  and this
> behavior is inconsistent with PF (outer).

Ok, I assume we will have above limitation after applying this patch, right?
If that's true we'd better claim this in the commit log as well as document it as a knowing issue.