Re: [e1000-devel] i40e: Intel XL710: Linux Debian 11: rx/tx-vlan-offload seems to be broken since 2.18.9
On 12/30/2022 11:15 AM, Andrey Kulikov wrote: Hello, I've got an Intel Fortville XL710-based Ethernet controller with 4 x 10GbE SFP+ ports. Platform is based on Intel Xeon CPU E5-2697 v4 Platform running Debian 11.6, kernel 5.10.0 # uname -a Linux 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux Current i40e driver: 2.22.8 (out-of tree, self-built from sources). Are you loading the 8021q.ko module? Setup: Two identical platforms, with absolutely identical hardware and software. Connected directly with LC-LC SR patchcord using Intel 10G SFP+ transceivers (FTLX8571D3BCV-IT it makes any difference). Issue: When I configure VLAN on HW interface - it doesn't work. When pinging via VLAN the other side is just do not see anything (tcpdump shows nothing). At the same time, if I ping on HW interfaces directly - it does work perfectly well. But it was working with i40e driver 2.18.9 half of a year ago, with Debian 11.4(? here I could be wrong) kernel. Relevant fragment from my /etc/network/interfaces on one side: auto enp132s0f0 iface enp132s0f0 inet static address 192.168.33.2 netmask 255.255.255.0 mtu 1500 auto enp132s0f0.545 iface enp132s0f0.545 inet static address 192.168.44.2 netmask 255.255.255.0 mtu 1500 Once the network setup is done, what does 'ip link' show? The other side looks identical except IP-addresses (they both end with '1'). Workaround: disable tx-vlan-offload and and rx-vlan-offload: ethtool -K enp132s0f0 tx-vlan-offload off rx-vlan-offload off Checked with CISCO NEXUS 7000 and NEXUS 9000 as remote counterparts - they behave identically to described above. Based on what you said I doubt it's switches or cables, but someting is up with your config. Current XL710 firmware is 8.15. But I've got adapters with firmware 7.something - there is no difference in behavior. Does it ring a bell? I don't recall hearing reports of other issues. Does it have something to do with the i40e driver? Is any further information required? When pinging, it would be useful to see what ethtool -S shows as changing, like ethtool -S enp132s0f0 ping -c2 192.168.33.1 ethtool -S enp132s0f0 arp -an output would be useful as well. ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet
[e1000-devel] i40e: Intel XL710: Linux Debian 11: rx/tx-vlan-offload seems to be broken since 2.18.9
Hello, I've got an Intel Fortville XL710-based Ethernet controller with 4 x 10GbE SFP+ ports. Platform is based on Intel Xeon CPU E5-2697 v4 Platform running Debian 11.6, kernel 5.10.0 # uname -a Linux 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux Current i40e driver: 2.22.8 (out-of tree, self-built from sources). Setup: Two identical platforms, with absolutely identical hardware and software. Connected directly with LC-LC SR patchcord using Intel 10G SFP+ transceivers (FTLX8571D3BCV-IT it makes any difference). Issue: When I configure VLAN on HW interface - it doesn't work. When pinging via VLAN the other side is just do not see anything (tcpdump shows nothing). At the same time, if I ping on HW interfaces directly - it does work perfectly well. But it was working with i40e driver 2.18.9 half of a year ago, with Debian 11.4(? here I could be wrong) kernel. Relevant fragment from my /etc/network/interfaceson one side: auto enp132s0f0 iface enp132s0f0 inet static address 192.168.33.2 netmask 255.255.255.0 mtu 1500 auto enp132s0f0.545 iface enp132s0f0.545 inet static address 192.168.44.2 netmask 255.255.255.0 mtu 1500 The other side looks identical except IP-addresses (they both end with '1'). Workaround: disable tx-vlan-offload and and rx-vlan-offload: ethtool -K enp132s0f0 tx-vlan-offload off rx-vlan-offload off Checked with CISCO NEXUS 7000 and NEXUS 9000 as remote counterparts - they behave identically to described above. Current XL710 firmware is 8.15. But I've got adapters with firmware 7.something - there is no difference in behavior. Does it ring a bell? Does it have something to do with the i40e driver? Is any further information required? Will be glad to provide any additional details. -- Best wishes, Andrey == Additional information: # ethtool -i enp132s0f0 driver: i40e version: 2.22.8 firmware-version: 8.15 0x800095c4 0.0.0 expansion-rom-version: bus-info: :84:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes # ethtool -m enp132s0f0 Identifier: 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC) Transceiver codes : 0x10 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 Transceiver type : 10G Ethernet: 10G Base-SR Transceiver type : Ethernet: 1000BASE-SX Encoding : 0x06 (64B/66B) BR, Nominal : 10300MBd Rate identifier : 0x02 (8/4/2G Rx Rate_Select only) Length (SMF,km) : 0km Length (SMF) : 0m Length (50um) : 80m Length (62.5um) : 30m Length (Copper) : 0m Length (OM3) : 300m Laser wavelength : 850nm Vendor name : Intel Corp Vendor OUI: 00:1b:21 Vendor PN : FTLX8571D3BCV-IT Vendor rev: A Option values : 0x00 0x3a Option: RX_LOS implemented Option: TX_FAULT implemented Option: TX_DISABLE implemented Option: RATE_SELECT implemented BR margin, max: 0% BR margin, min: 0% Vendor SN : AT3000C Date code : 150113 Optical diagnostics support : Yes Laser bias current: 7.782 mA Laser output power: 0.5434 mW / -2.65 dBm Receiver signal average optical power : 0.4734 mW / -3.25 dBm Module temperature: 30.60 degrees C / 87.08 degrees F Module voltage: 3.3269 V Alarm/warning flags implemented : Yes Laser bias current high alarm : Off Laser bias current low alarm : Off Laser bias current high warning : Off Laser bias current low warning: Off Laser output power high alarm : Off Laser output power low alarm : Off Laser output power high warning
