Hi All,

I'm encountering an issue with XL710 SR-IOV on KVM for VLAN packets with
DPDK-22.11.0 version. 

Issue Description: I have disabled RTE_ETH_RX_OFFLOAD_VLAN_STRIP in
rte_eth_conf and calling rte_eth_dev_configure and expecting my dpdk
application to receive the packets with vlan tags. Later I added some vlans
using rte_eth_dev_vlan_filter() and I see that the vlan is getting stripped off
 for the incoming packets. 

Setup Details:(KVM SR-IOV)

KVM Host: Ubuntu 20.04.6 LTS: kernel version: 5.4.0-216-generic #236-Ubuntu
NIC: XL710
3b:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for
40GbE QSFP+ (rev 02)
3b:00.1 Ethernet controller: Intel Corporation Ethernet Controller XL710 for
40GbE QSFP+ (rev 02)
i40e PF Driver: Out of tree 2.20.12
Firmware: 9.00/9.40 
DPDK Version: 22.11.0


Observation/Analysis:

I could see that even after disabling RTE_ETH_RX_OFFLOAD_VLAN_STRIP offload
flag, when I receive the packets, the mbuf offload flags (RTE_MBUF_F_RX_VLAN |
RTE_MBUF_F_RX_VLAN_STRIPPED) are set inside the mbuf. This confirms that the
driver is stripping off the vlans.


I tried with recommended PF driver version for DPDK-22.11.0 as per
https://mails.dpdk.org/archives/dev/2023-November/281700.html and DPDK-22.11
release note https://doc.dpdk.org/guides/rel_notes/release_22_11.html. Still it
did not help.


       Intel® Ethernet Converged Network Adapter XL710-QDA2 (2X40G)
    Firmware version(PF): 9.00 0x8000ce86 1.3179.0
    Device id (pf/vf): 8086:1583 / 8086:154c
    Driver version(out-tree): 2.20.12 (i40e)
    Driver version(in-tree): 5.15.0-46-generic (i40e)


Upon debugging further, I came across a DPDK commit:
https://github.com/DPDK/dpdk/commit/e25c7ed114b296ddaa583427824acc30bcf9c85d
which says it sets the vlan_strip on in PF when we set vlan filter on VF. 

I picked the fix, but still it did not help.

Later when I debugged further, I found that the vf_cap_flags is set to
VIRTCHNL_VF_OFFLOAD_VLAN_V2 for the above PF driver and still it sets the
vlan_strip on. I extended the dpdk commit for the VIRTCHNL_VF_OFFLOAD_VLAN_V2
case which fixed the issue.


I just want to know if it's a known issue for the VIRTCHNL_VF_OFFLOAD_VLAN_V2
case. I understand it's a known issue for VIRTCHNL_VF_OFFLOAD_VLAN_V1 and dpdk
has a fix for it. 
Do we need to add the fix for VIRTCHNL_VF_OFFLOAD_VLAN_V2 as well. Can we
mainstream it? If yes, please let me know so that I can raise a pull request
for it, if required.

Regards
Amiya