[Bug 193053] New: ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: ncrogers at 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 at 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 at 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.