From: Iain Barker <iain.barker@oracle.com>
To: users@dpdk.org
Subject: [dpdk-users] VLAN tags always stripped on i40evf [VMware SR-IOV]
Date: Tue, 10 Oct 2017 06:48:36 -0700 (PDT) [thread overview]
Message-ID: <6a275bea-214e-489b-ba42-df70328b3854@default> (raw)
I have a problem trying to get VLAN tagged frames to be received at the i40evf PMD.
Specifically, there is no connectivity on VMware i40e media interface configured as SR-IOV when VLANs are used, but it works fine for non-VLAN tagged frames. It seems the VLAN headers are being stripped before they reach the DPDK application, but the exact same configuration works fine for native Linux driver with VLANs.
Host is VMware ESXi 6.5, XL710 interfaces (i40e) and SR-IOV enabled at the vswitch PF, configured as VLAN trunking mode (VLAN tags through to guest). An external system sends VLAN 8 tagged frames to the guest VM interface - the trivial testcase is to use ICMP 'ping' across the VLAN from eth1.8 on another Linux system.
With Linux 3.10 native i40evf driver as the guest VM, the VLAN 8 tagged frames are received on i40evf, and the outgoing ICMP reply is tagged correctly as VLAN 8
(verified with wireshark that the VLAN 8 header is present on the frames)
With DPDK PMD (tried DPDK 16.7, 16.11, 17.8) running testpmd icmpecho, the frames are received without any VLAN tag, so the reply is sent untagged and the 'ping' fails
(verified using dpdk-pdump that the frames have VLAN stripped)
Switching from i40evf to using vmxnet3 PV interface, testpmd works correctly with VLAN tagged frames.
Also sending the icmp ping without VLAN headers on the i40evf, testpmd works correctly for the untagged case.
So the problem seems to be specific to DPDK i40e PMD when using VLANs in SR-IOV mode.
My first thought was maybe VMware was configuring the PF to forcing VLAN stripping, but as Linux native i40evf driver is able to correctly, the VLANs must be able to pass from PF to the VF. Maybe DPDK is doing something 'different' compared to Linux for setting up the VF, and breaking VLAN tagging as a result? But I don't know what that might be.
Any ideas what I am doing wrong? I've included the test sequence below, which trivially reproduces the difference in behavior.
ps. I also tried different firmware and driver versions on the host interface, including the versions listed in the release note for each DPDK release, with the same exact behavior.
---
Steps to configure the Linux environment:
ifconfig eth0 2.2.2.3
vconfig add eth0 8
ifconfig eth0.8 8.8.8.3
dumpcap -i eth0
Ping to the 2.2.2.3 and 8.8.8.3 IP addresses from the far-end device
Observe that packets in the pcap (view using wireshark) are untagged for 2.2.2.3 and 8.8.8.3 tagged vlan 8, for both the icmp echo and reply
Steps to configure the DPDK environment:
ifconfig eth0 down
dpdk-devbind.py --bind=igb_uio eth0
testpmd --log-level=8 --pci-whitelist 0000:03:00.0 -- --interactive --forward-mode=icmpecho
set verbose 1
set promisc 0 off
set fwd icmpecho
vlan set strip off 0
vlan set filter off 0
start
Note: Verify that vlan strip and vlan filter are both disabled in 'show port info all'.
>From another session of the Linux host, run the dpdk-pdump tool to capture the trace:
dpdk-pdump - --pdump 'port=0,queue=*,rx-dev=/tmp/capture.pcap,tx-dev=/tmp/capture.pcap'
Ping to the 2.2.2.3 and 8.8.8.3 IP addresses from the far-end device
Observe that all packets in the pcap appear as untagged for both icmp echo and reply
---
thanks,
Iain
next reply other threads:[~2017-10-10 13:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-10 13:48 Iain Barker [this message]
2017-10-11 13:19 ` Iain Barker
2017-10-27 2:23 ` Xing, Beilei
2017-10-27 13:05 ` Iain Barker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a275bea-214e-489b-ba42-df70328b3854@default \
--to=iain.barker@oracle.com \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).