Bug 1270848
| Summary: | vlan tag is not stripped in the packet when received in a vm which is using dpdk on a VF netcard. | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Wanglujing <065903> |
| Component: | openstack-neutron | Assignee: | Franck Baudin <fbaudin> |
| Status: | CLOSED NOTABUG | QA Contact: | Ofer Blaut <oblaut> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | Foreman (RHEL 6) | CC: | amuller, chrisw, fbaudin, jean-mickael.guerin, nyechiel, srevivo, vincent.jardin, yrachman |
| Target Milestone: | --- | Keywords: | ZStream |
| Target Release: | 8.0 (Liberty) | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-03 12:30:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Having DPDK in the VM makes debugging difficult. Please use a regular kernel driver and go on without DPDK in the VM to debug. The configuration of the NIC is done by the hypervisor, and is independent of what is running in the guest: it can be Linux kernel, DPDK, FreeBSD, ... The fact that VLAN will be stripped or not is an ixgbe_pf configuration issue or a bug on the hypervisor (ixgbe_pf bug?). Closing this bug, please reopen if youcan replicate it without DPDK in the guest but a regular RHEL in the guest. |
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: