ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included)

[Nick Rogers]

On Tue, Aug 26, 2014 at 4:16 PM, Nick Rogers <ncrogers at gmail.com> wrote:

>
>
>
> On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>
>> Hi,
>>
>> I'm not surprised the legacy tx path has bitrotted there.
>>
>> Please file a bug with this - https://bugs.freebsd.org/submit/ - and
>> then just keep poking people until it's done.
>>
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053
>

Poke. Looking for some triage?


>
>> Thank!
>>
>>
>> -a
>>
>>
>> On 26 August 2014 13:42, Nick Rogers <ncrogers at gmail.com> wrote:
>> > Hello,
>> >
>> > I am trying to get the ixgbe driver + PF/ALTQ working under stable/9.
>> > Initially, loading a PF rulset 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 following 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.
>> >
>> > Index: ixgbe.c
>> > ===================================================================
>> > --- ixgbe.c (revision 270665)
>> > +++ ixgbe.c (working copy)
>> > @@ -1543,7 +1543,7 @@
>> >   IXGBE_TX_LOCK(txr);
>> >   ixgbe_txeof(txr);
>> >  #ifdef IXGBE_LEGACY_TX
>> > - if (!IFQ_DRV_IS_EMPTY(ifp->if_snd))
>> > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
>> >   ixgbe_start_locked(txr, ifp);
>> >  #else
>> >   if (!drbr_empty(ifp, txr->br))
>> > @@ -2091,7 +2091,11 @@
>> >      (paused == 0))
>> >   ++hung;
>> >   else if (txr->queue_status == IXGBE_QUEUE_WORKING)
>> > +#ifndef IXGBE_LEGACY_TX
>> >   taskqueue_enqueue(que->tq, &txr->txq_task);
>> > +#else
>> > + taskqueue_enqueue(que->tq, &que->que_task);
>> > +#endif
>> >          }
>> >   /* Only truely watchdog if all queues show hung */
>> >          if (hung == adapter->num_queues)
>> > @@ -3327,10 +3331,6 @@
>> >   tx_buffer->map = NULL;
>> >   }
>> >   }
>> > -#ifdef IXGBE_LEGACY_TX
>> > - if (txr->br != NULL)
>> > - buf_ring_free(txr->br, M_DEVBUF);
>> > -#endif
>> >   if (txr->tx_buffers != NULL) {
>> >   free(txr->tx_buffers, M_DEVBUF);
>> >   txr->tx_buffers = NULL;
>> > ===================================================================
>> >
>> > Using a stable/9 kernel with the above 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!
>> >
>> > -Nick
>> > _______________________________________________
>> > freebsd-net at freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>
>