Bug 1270851 - vlan tag is not stripped in the packet when received in a vm which is using dpdk on a VF netcard.
vlan tag is not stripped in the packet when received in a vm which is using ...
Status: CLOSED DUPLICATE of bug 1270849
Product: Red Hat OpenStack
Classification: Red Hat
Component: kernel (Show other bugs)
Foreman (RHEL 6)
x86_64 Linux
unspecified Severity medium
: ---
: 8.0 (Liberty)
Assigned To: Red Hat Kernel Manager
Jean-Tsung Hsiao
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-12 10:04 EDT by Wanglujing
Modified: 2015-10-14 09:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-14 09:41:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wanglujing 2015-10-12 10:04:41 EDT
Description of problem:

   my customer boot a vm attached 2 sriov ports , and running an application based DPDK-1.7.1, now they found
the packets which the vm's netcard is receiving are tagged with vlan ID.

[root@controller1 ~(keystone_admin)]# neutron net-show WRNC_SRVWithoutPreDefine.EXTERMEDIA.WRNC
+---------------------------+------------------------------------------+
| Field                     | Value                                    |
+---------------------------+------------------------------------------+
| admin_state_up            | True                                     |
| id                        | 6568aaf6-7dda-4dba-aa44-9adc08f8bfd1     |
| name                      | WRNC_SRVWithoutPreDefine.EXTERMEDIA.WRNC |
| provider:network_type     | vlan                                     |
| provider:physical_network | physnet1                                 |
| provider:segmentation_id  | 106                                      |
| router:external           | False                                    |
| shared                    | True                                     |
| status                    | ACTIVE                                   |
| subnets                   | 925db690-f2e8-4d46-80e9-fa743be85f69     |
| tenant_id                 | da6ec2a568604a19af759c68221fb99c         |
+---------------------------+------------------------------------------+


[hujun@host0 sosreport-compute3.zte.com.sriov-dpdk-vlan01-20150922172104]$ ip l show ens1f0  | grep 106
    vf 58 MAC 00:19:c6:18:01:25, vlan 106, spoof checking on, link-state auto

the vm is located in host compute3.zte.com, they can dump packet on nic which MAC address is 00:19:c6:18:01:25 using
their tool in the vm.

# DPDK_DumpPkt(1,0)
rx_dump_pkt :1,tx_dump_pkt:0
value = 30 = 0x1e(32);value = 30=0x1e(64)
ushell command finished

 Port 8 Packet data addr is 0x7f8d1df56080, datalen is 254
 0x7f8d1df56080 :  0019c618   01250022   9366ac20   8100006a
 0x7f8d1df56090 :  08004500   00ecd532   0000fe84   ae1d0405
 0x7f8d1df560a0 :  29010b00   00380420   04203000   0029c3e8
 0x7f8d1df560b0 :  63bb0200   00cc381c   4a7d0008   00000010
 0x7f8d1df560c0 :  0010381c   4a7d0007   00b0bf48   71d0899a
 0x7f8d1df560d0 :  f8d8596b   c7bef41d   631d3820   9a537011
 0x7f8d1df560e0 :  01002004   20042900   00307d4a   1c380000
 0x7f8d1df560f0 :  02001000   10007d4a   1c382800   00300100
 0x7f8d1df56100 :  00000000   04003800   000b0000   00000000
 0x7f8d1df56110 :  00000000   00000000   00000000   00000000
 0x7f8d1df56120 :  00000000   00000000   00000000   00000000
 0x7f8d1df56130 :  00000000   00000000   00000000   00000000
 0x7f8d1df56140 :  00000000   00000000   00000000   00000000
 0x7f8d1df56150 :  00000000   00000000   00000000   00000000
 0x7f8d1df56160 :  00000000   00000000   00000000   00000000
 0x7f8d1df56170 :  00000000   00000005   00080405   29010480

if they apply a patch of DPDK located in the vm, we can find the packet haven't the VLAN ID.
# DPDK_DumpPkt(1,0)
Port 8 Packet data addr is 0x7f8d2004cc00, datalen is 270
 0x7f8d2004cc00 :  0019c618   01250022   9366ac20   08004500
 0x7f8d2004cc10 :  0100dd3f   0000fe84   c6300a04   02020a02
 0x7f8d2004cc20 :  02020197   3900b001   00a9f759   28ba0300
 0x7f8d2004cc30 :  0010b001   04c60001   ffd70000   00000003
 0x7f8d2004cc40 :  002bbef7   d7c40000   18c50000   0000200c
 0x7f8d2004cc50 :  22090115   00000101   76400e60   01203326
 0x7f8d2004cc60 :  1b803500   010a0403   0e000003   0039bef7
 0x7f8d2004cc70 :  d7c50000   18c60000   0000200c   22094123
 0x7f8d2004cc80 :  00000101   6a401c2c   0a202e32   1b803500
 0x7f8d2004cc90 :  010a0403   0e600920   31a01b80   3500010a
 0x7f8d2004cca0 :  04030e00   00000003   002bbef7   d7c60000
 0x7f8d2004ccb0 :  18c70000   0000200c   220b4115   00000101
 0x7f8d2004ccc0 :  76400e60   0120317c   1b803500   010a0403
 0x7f8d2004ccd0 :  0e000003   0039bef7   d7c70000   18c80000
 0x7f8d2004cce0 :  0000200c   220b8123   00000101   6a401c2c
 0x7f8d2004ccf0 :  0a202a5c   1b803500   010a0403   0e600920
 0x7f8d2004cd00 :  2c5c1b80   3500010a   04030e00   00004000

compared the two packets, we can find the VLAN indentification "8100006a" , within that 0x6a is the VLAN ID 106.
although, they think the VLAN tag can be stripped on openstack platform.

on the host compute3.zte.com ,  "ens1f0" is PF whose driver is ixgbe 

Version-Release number of selected component (if applicable):
host:rhel7.1, Openstack platform 6
vm : rhel7.1

How reproducible:100% 
Steps to Reproduce:
you can reproduce it but it is difficult to see the issue because it is difficult to dump raw packet in vm when using DPDK.
In fact, to help to understand the issue , you can take two server ,each with one 82599 netcard,config SRIOV, then run a vm in each server, set the same Vlan id for VF , 
in the vm, you can modify ixgbevf souce code and print the vlan tag in receive packet path.
you can refer it like https://access.redhat.com/support/cases/#/case/01512268


Actual results:
vlan tag is not striped.

Expected results:
vlan tag is striped by hardware, not by software.

Additional info:
Comment 2 John W. Linville 2015-10-14 09:41:23 EDT

*** This bug has been marked as a duplicate of bug 1270849 ***

Note You need to log in before you can comment on or make changes to this bug.