Date: Tue, 26 Aug 2014 23:13:11 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 193053] New: ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Message-ID: <bug-193053-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 Bug ID: 193053 Summary: ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Product: Base System Version: 11.0-CURRENT Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: ncrogers@gmail.com Created attachment 146347 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=146347&action=edit ixgbe.c fix IXGBE_LEGACY_TX The ixgbe driver + PF/ALTQ under stable/9 and likely stable/10 and head is broken. Initially, loading a PF ruleset with ALTQ enabled fails on an ix interface, reporting "ix0: driver does not support altq". This is similar to the behavior over the last few years when dealing with the igb driver. However, I have been using ALTQ + igb with great success by defining IGB_LEGACY_TX in the e1000/igb driver code. I noticed that ixgbe has a similar define IXGBE_LEGACY_TX to enable the legacy, non-multiqueue transmit behavior, that also "enables" ALTQ support. After adding the IXGBE_LEGACY_TX define to ixgbe source, building the driver fails with the following compile errors: /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_msix_que': /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '->' (have 'struct ifaltq') /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '->' (have 'struct ifaltq') /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer': /usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no member named 'txq_task' /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_free_transmit_buffers': /usr/src/sys/dev/ixgbe/ixgbe.c:3255: error: 'struct tx_ring' has no member named 'br' /usr/src/sys/dev/ixgbe/ixgbe.c:3256: error: 'struct tx_ring' has no member named 'br' So it seems that the IXGBE_LEGACY_TX path no longer compiles successfully, and perhaps never did? Using e1000 as a reference, fixing the pointer error, and looking at previous revisions of ixgbe.c, I was able to come up with the attached patch that got the driver to compile while having IXGBE_LEGACY_TX defined. Note that the following svn diff is against HEAD, which as far as I can tell contains the same broken IXGBE_LEGACY_TX path as stable/9 and stable/10. Using a stable/9 kernel with the attached patch allowed me to load my PF ruleset on a machine with an ixgbe interface and ALTQ enabled. i.e. I no longer received the "driver does not support altq error". Queueing on the ix interface now appears to work as it should. I am hoping someone can help verify my work and perhaps audit and correct the IXGBE_LEGACY_TX path currently in the svn tree. Also, FWIW, here is relevant pciconf output for the ixbge card. ix0@pci0:1:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 0023faffff300715 ecap 000e[150] = unknown 1 ecap 0010[160] = unknown 1 ix1@pci0:1:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 0023faffff300715 ecap 000e[150] = unknown 1 ecap 0010[160] = unknown 1 Thanks! -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193053-8>