This issue may be fixed by this upstream commit:
commit f60439bc21e3337429838e477903214f5bd8277f
Author: Alexander Duyck <alexander.h.du...@intel.com>
Date: Thu Aug 11 14:51:56 2016 -0700
ixgbe: Force VLNCTRL.VFE to be set in all VMDq paths
When I was adding the code for enabling VLAN promiscuous mode with SR-IOV
enabled I had inadvertently left the VLNCTRL.VFE bit unchanged as I has
assumed there was code in another path that was setting it when we enabled
SR-IOV. This wasn't the case and as a result we were just disabling VLAN
filtering for all the VFs apparently.
Also the previous patches were always clearing CFIEN which was always set
to 0 by the hardware anyway so I am dropping the redundant bit clearing.
Fixes: 16369564915a ("ixgbe: Add support for VLAN promiscuous with SR-IOV")
Signed-off-by: Alexander Duyck <alexander.h.du...@intel.com>
Tested-by: Andrew Bowers <andrewx.bow...@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com>
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1658491
Title:
VLAN SR-IOV regression for IXGBE driver
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
New
Status in linux source package in Yakkety:
New
Status in linux source package in Zesty:
In Progress
Bug description:
IXGBE driver, for SR-IOV setups, is misbehaving with VLANs.
Description from affected user:
- Create 2 networks (sriov 100 and 102 vlan)
# neutron net-create --provider:physical_network=PHY0
--provider:network_type=vlan --provider:segmentation_id=100 PHY0_vlan_100
# neutron net-create --provider:physical_network=PHY0
--provider:network_type=vlan --provider:segmentation_id=102 PHY0_vlan_102
- Create the subnets:
# neutron subnet-create PHY0_vlan_100 192.168.50.0/24
# neutron subnet-create PHY0_vlan_102 192.168.60.0/24
- Create the neutron ports:
# neutron port-create e450757f-fec6-466e-bb21-a42a2019fe6b --name
vlan_100_port1 --vnic-type direct
# neutron port-create 32c468ed-7e1e-4267-bbbf-ec72d33e4454 --name
vlan_102_port1 --vnic-type direct
- Boot 2 VMs on 2 different hosts (add only 1 port to each of them +
ovs dhcp network):
# nova boot --flavor 789 --image ubuntu --nic
net-id=1cf2a512-8963-413d-a745-99e758789c2b --nic
port-id=92cf2867-cc0a-4e0d-aa87-14a345cdd708 102_port1_compute6 --key-name mkey
--config-drive true --availability-zone nova:compute-0-6.domain.tld --poll
# nova boot --flavor 789 --image ubutnu --nic
net-id=1cf2a512-8963-413d-a745-99e758789c2b --nic
port-id=baec6fd6-933d-4c58-94b6-44c50405d409 100_port1_compute5 --key-name mkey
--config-drive true --availability-zone nova:compute-0-5.domain.tld --poll
- After the VMs booted, configure the VFs:
root@102-port1-compute6:~# ifconfig eth1 192.168.34.6 up
root@100-port1-compute5:~# ifconfig eth1 192.168.34.5 up
If I ping each other it works but it shouldn't work because in this
case both of the VMs's interface (host VF) are in different vlans:
- Pinging shouldn't work because the VMs interface (host VF) are in
different VLANs.
root@compute-0-5:~# ip link show eth6
8: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2140 qdisc mq state UP mode
DEFAULT group default qlen 1000
link/ether a0:36:9f:3f:1a:64 brd ff:ff:ff:ff:ff:ff
vf 5 MAC fa:16:3e:f0:2c:e2, vlan 100, spoof checking on, link-state auto
root@compute-0-6:~# ip link show eth5
8: eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2140 qdisc mq state UP mode
DEFAULT group default qlen 1000
link/ether a0:36:9f:3f:20:88 brd ff:ff:ff:ff:ff:ff
vf 7 MAC fa:16:3e:ce:69:41, vlan 101, spoof checking on, link-state auto
But user can ping both VMs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1658491/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
